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In this Issue 

HP's briefcase-portable computers. The Portable and the Portable Plus, 
are designed for professional people who need the power of a personal 
computer when they are away from their offices. The Portable has as much 
memory and processing power as a typical desktop personal computer, and 
the Portable Plus has a larger memory capacity and other enhancements. 
Both computers use the same industry-standard MS ""-DOS operating sys- 
tem as most desktop PCs. According to HP studies, over 80% of HP Portable 
owners use their portable computer as a go-anywhere complement to their 
desktop PC, running the same software on both machines and transferring 
data between them as needed. In this issue, the designers of The Portable and the Portable Plus 
give us the inside story of these machines. After a discussion of the differences between the 
portable and office environments and an overview of the design (page 4). we're given a tour of 
the I/O and data communications facilities (page 14), and a description of the Personal Applications 
Manager, which gives a novice user easy access to most of the features of the MS-DOS operating 
system (page 18) Memory management, including the concept of the "electronic disc" and 
memory expansion in the Portable Plus, is the subject of the article on page 21 . The fast-turnaround 
design of a hybrid controller for the Portable Plus' 25-line liquid-crystal display is described on 
page 25, and the article on page 28 tells how the Portable Plus can be customized by the addition 
of special ROMs. Using a ROM Development Package supplied by HP, customers and software 
developers can produce custom ROMs for this purpose with no assistance from HP. 

The HP-UX operating system is HP's version of AT&T Bell Laboratories' UNIX " System V™ 
operating system, with enhancements. Described on page 34 is the latest HP-UX release for HP 
9000 Series 300 Engineering Workstations. This release provides features such as virtual memory 
and local area networking, and several new features including support for device I/O, X.25 wide 
area networking, and a window-oriented human interface for the new Series 300 bit-mapped 
displays. 

LANs — local area networks — are networks of computers located entirely within a single building 
or at a single site. Various proposed and accepted standards, or protocols, define the physical 
interconnections, data formats, and network control procedures that guarantee that the computers 
on a given LAN will communicate effectively, even if they are manufactured by different companies. 
A widely accepted protocol is defined by IEEE Standard 802.3, which is nearly identical to the 
Ethernet protocol developed by Xerox Corporation and first promulgated by Xerox, Digital Equip- 
ment Corporation, and Intel Corporation. On page 42, a group of designers from HP's Colorado 
Telecommunications Division describe the design of a new protocol analyzer for troubleshooting 
and maintaining IEEE 802.3 and Ethernet local area networks. Capable of monitoring, simulating, 
and analyzing traffic on a LAN, the HP 4971 S provides a powerful filtering capability — 1 6 user-de- 
finable filters for selective data capture — and the ability to display up to 500 node identifiers as 
easy-to-remember names. 

-R. P. Dolan 
Editor 



What's Ahead 

Next month's issue will present the processor and I O system definitions of the new HP Precision 
Architecture. Other articles will describe the HP Precision simulator and performance analysis 
methods. 
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Design of HP's Portable Computer Family 



The Portable and Portable Plus Computers are compact, 
lightweight, battery-powered personal computers with built- 
in software and 80-character-line liquid-crystal displays 
designed for use by professionals who need portable 
computing capability in their work. 

by John T. Eaton, Carl B. Lantz, Clifford B. Cordy, Jr., James W. Pearson, Michael J. Barbour, Courtney 
Loomis, and Ella M. Duyck 



IN MAY 1984. Hewlett-Packard introduced The Portable 
Personal Computer (Fig. 1). HP's concept for applying 
the power of personal computing to problems in the 
field. The Portable contains as much memory and process- 
ing power as a typical personal computer, but is battery- 
powered and the same size as a three-ring notebook. More 
recently, the Portable Plus (Fig. 1) was added lo HP's port- 
able computer family. The Portable Plus has a larger dis- 
play, enhanced data communications, and the greatest 
memory capacity (1.28M bytes) currently available in a 
battery-powered computer, 

Portability and Enhancements 

Although HP's portable computers are as powerful as 
many desktop versions, they have a number of enhance- 
ments that are necessary to satisfy the requirements of the 



portable user: 

■ Electronic disc 

■ Operating system in ROM 

■ Video interface (Portable Plus only) 

■ Memory expansion (Portable Plus only) 

■ Permanently resident applications software 

■ 80-character-per-line liquid-crystal display 

■ Built-in modem (optional in Portable Plus) 

■ Personal Applications Manager 

■ Built-in RS-232-C/V.24 and HP-IL interfaces 

■ Battery power with power-saving features. 

Portable computers are used differently on the road than 
they are at a desk. The typical desktop computer takes 
several minutes after it is turned on to run self-tests and 
load its operating system from disc. Hence, many desktop 
users turn their machines on at the start of the day and 




Fig. 1. The Portable (left) comes complete with MS" -DOS 2.11, HP's Personal Applications 
Manager, MemoMaker, and Terminal Emulation software, and I -2-3 " from Lotus " The Portable 
contains 272K bytes ol memory, a 300-baud modem, an RS-232-CIV.24 serial interface, an 
HP-IL interface, a W-line-by-80-column liquid-crystal display, lead-acid battery power supply 
and a full-size keyboard. The Portable Plus ( right) comes complete with MS-DOS 2 11. and 
HP's Personal Applications Manager. SECURE, HPUnk, EDLIN, and Terminal Emulation soft- 
ware The Portable Plus features a 25-lme-by-80-column antiglare liquid-crystal display. 128K 
bytes of RAM. an RS-232-OV 24 serial interface, an HP-IL interface, a full-size keyboard with 
embedded numeric keypad, lead-acid battery power supply, and two expansion drawers for 
additional RAM and/or application ROMs A built-in 30011 200-baud modem is optional 
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leave them running all day long. Portable computers, on 
the other hand, are normally turned on and off quite fre- 
quently. Portable users turn on their machines when they 
need to use them and then turn them off when they are 
finished. It is not acceptable to force a user to wait during 
a lengthy start-up sequence each time a portable computer 
is turned on. Access to data must be quick and easy. 

HP's portable computers can use a portion of their inter- 
nal memory as an electronic disc. User files can be stored 
in battery-backed CMOS RAM and application programs 
are kept in ROM. This electronic disc is faster than a hard 
disc and safe from the problems of disc wear and head 
crashes. 

You can turn on an HP portable computer, select an 
application, and load in a data file in about 15 seconds. 
To provide this capability, several features common to desk- 
top systems were modified for the portable environment. 
Automatic power-on self-tests are replaced with a user- 
selected self-test. This allows for battery backup of the elec- 
tronic disc so that it retains all of its files while the unit 
is powered off. A typical desktop system cannot do this 
because its power-on diagnostics usually erase all the files 
in an electronic disc each time the computer is powered on. 

The operating system often must be reloaded during a 
typical computer session. The Portable and Portable Plus 
have MS "-DOS completely in ROM so it can be loaded 
faster than from a hard disc. Portions of the operating sys- 
tem drivers are executed directly from the ROM. This pro- 
vides a double bonus in thai this code does not have to be 
copied each time the computer is turned on. and the RAM 
space normally required to hold this code is available for 
the user's applications and data. 

New features for the Portable Plus include video interface 
capability and memory expansion. Whereas The Portable 
is a closed system, the Portable Plus has an open architec- 
ture with two user-installable plug-in ports. This allows 
(he product to be enhanced from the base machine to a 
higher-performance machine. (See "Plug-In Memory" on 
page 9.) The Portable Plus can be configured with a ROM 
drawer that can contain up to 1.5 megabytes of ROM or' 
KPROM code. Instead of having to carry a disc for each 
application, a user can install desired applications perma- 
nently inside the machine and have them available at a 
moment's notice. The Portable comes with word processing 
(Memomaker). terminal emulation, and spreadsheet, 
graphics, and file management (1-2-3" from Lotus") soft- 
ware built-in. 

The Portable Plus incorporates several new technologies. 
Its liquid-crystal display (LCD) is larger (25 lines) than The 
Portable's LCD (16 lines) and its optional built-in modem 
operates at 300 and 1200 baud compared to The Portable's 
standard 300-baucl modem. Not so obvious is an increase 
in packaging density achieved with the use of lM-bitCMOS 
ROMs. Other advances, such as low-power RS-232-C/V.24 
serial interface drivers, result in increased battery life. 

There are many differences between the portable and 
desktop environments that must be addressed in the design 
of any portable computer. One example is documentation 
and ease of use. Portable computer users are not likely to 
have all the computer and software documentation with 
them at nil limes. Programs should be easy to use and have 



as much on-line help as possible. The Personal Applica- 
tions Manager (PAM. see article on page 18) and its built-in 
help facilities are resident in The Portable and Portable 
Plus to achieve these objectives. 

Portable computers are used mostly in situations where 
desktop computers cannot be used because of their size 
and power requirements. But there are times when it is 
advantageous to be able to use a portable computer in a 
desktop environment. Battery-powered portables have the 
built-in advantage of an uninterruptable power source that 
can power the computer for hours. A desktop computer 
user who needs dependable computing might otherwise 
spend hundreds of dollars for a device that can power a 
desktop computer for only 15 minutes after a power failure. 

The smaller size of a portable computer can be another 
advantage. Many users discover that there is not much 
room left on a desk after putting a normal desktop computer 
on it. A portable computer takes up very little desk space 
when not in use and can even be stored out of sight in a 
drawer. It is easy to set up and can be fully operational 
with the touch of a key. Portable computers are quieter 
since they do not require noisy fans and they do not anchor 
the user to a desk. When peripheral devices such as a 
printer are needed, they can be connected to HP's portable 
family by using the HP-IL (Hewlett-Packard Interface 
Loop), 1 which provides both a quick easy connection and 
a thin cable that is easy to handle. 

The built-in software has several features that help pro- 
long battery life (see box on page 10). A time-out function 
powers off the computer if it has been inactive for a period 
of time. This time-out is nondestructive, meaning that a 
touch of a key restores the computer to exactly where it 
was when it timed out. If you are called away from the 
computer and it times out while you are gone, you can 
pick up exactly where you left off when you return. This 
also works when the computer shuts down because of a 
nearly discharged battery. A user has up to one week after 
the computer shuts down to recharge its battery and be 
able to continue with no loss of data or programs. 

Another method used to prolong battery life is to put the 
computer into a low-power mode when it is not actively 
performing a calculation. Implementing this function is 
somewhat tricky because a portable computer could be 
running an application that was not written with battery 
life in mind. The Portable and Portable Plus use a special 
algorithm that monitors I/O use and the frequency of 
keyboard status checks to decide if an application is doing 
something or simply waiting for the user to press a key. If 
the algorithm considers that the computer is waiting, then 
it places the computer in the low-power mode until the 
next key press. 

Hardware Design 

Putting all the components for a complete personal com- 
puter into a box the size of a notebook is not a trivial task, 
but necessary for the design of a portable system. It also 
requires that the circuitry consume the minimum amount 
of power possible to conserve battery life. CMOS circuitry 
was used throughout The Portable and Portable Plus Com- 
puters to achieve this goal. The hardware system (Fig. 2) 
is designed around a CMOS version of the 80C86 micropro- 
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Inside the LCDs for The Portable and Portable Plus 



A truly portable computer requires a display technology that 
meets the requirements ol portable design In the case of The 
Portable and Portable Plus Computers, this means low power 
consumption, light weight, ruggedness, and a large display tor- 
mat An 80-character screen width, with a minimum of sixteen 
alphanumeric lines and lull graphics capability was determined 
to be the smallest acceptable size Use m HP products targeted 
for a competitive market made a low price a particularly critical 
criterion in choosing the type of display 

In examining potential technologies, a liquid-crystal display 
(LCD) was the only alternative at the time that came dose to 
meeting all these constraints The use of an LCD provides a 
very-low-power (about an eighth of a watt) sturdy display The 
low power requirements of the reflective LCDs chosen for this 
application stem from the fact that they are nonemissive (i e , 
they have no internal light source). Since these thin displays use 
ambient light as their source, there are some trade-offs in using 
this technology Reflective LCDs are most useful in well-lighted 
situations where the overhead light is diffuse and plentiful Direct 
light can cause problems with glare Lack of adequate light will 
result in poor readability Even in adequate light, the technique 
used to drive these panels only gives acceptable contrast over 
a small range of viewing angles. To accommodate this limitation, 
the LCD panel is mounted in a display case with adjustable till 

The particular type of LCD used in HP's portable computers 
is a twisted-nematic LCD Nematic refers to the phase of the 
liquid-crystal material In the nematic phase, the long axes of 
copianar liquid-crystal molecules align in a parallel orientation 
A common analogy is that of pencils thrown into a box. When 
the box is shaken, the pencils representing the molecules tend 
to line up parallel to one another Layers of this nematic LC are 
sandwiched between two pieces of grooved glass The glass on 
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Fig. 1. Crass section ol liquid-crystal display. 



the top has grooves on an axis perpendicular to that of the bottom 
glass As a result, the surface tension at each glass-LC interface 
causes successive planes of the medium to form a spiral, twisting 
upward from the lower glass to the upper glass Optically this 
twisted structure has a special property — it is capable of rotating 
linearly polarized light By placing polarizing filters above and 
below this glass sandwich, each parallel to the texturing on the 
adjacent glass, a polarizer with a 90-degree twist is formed (see 
Rg. 1) 

If a voltage is applied perpendicularly across this medium, 
the helical shape of the LC structure is perturbed and the LC 
molecules align m the direction of the electric field lines, no 
longer twisting the light polarization In this condition, the effects 
of the surface polarizers cancel and incident light is absorbed 
Thus, in the relaxed state, the LCD passes polarized light and 
m the excited state the light is blocked. For the LCD. the potential 
is applied across the LC medium using transparent row and 
column conductors etched on the inner surfaces of the glass 
plates 

By placing a reflector on the rear surface of the panel, incident 
light can be used as the source for this light modulator The fact 
that the liquid-crystal structure is affected by the application of 
voltage rather than the passing of current (it is a capacitive ele- 
ment), along with the reflector and some intelligent design of the 
drive circuitry, minimizes the power needed by this type of dis- 
play 

The LCD panels purchased for HP's portable computing prod- 
ucts are procured as a complete assembly having a four-quad- 
rant multiplexed display and are interfaced with a printed circuit 
board containing surface-mounted drive circuitry. Panels with 
this type of configuration were chosen because they offer the 
best possible contrast for a large number of rows. Also for this 
reason, a 480-pixel-wide display, rather than the conventional 
640 pixels, was chosen. All that the designer needs to supply 
for the display are serial bits for each quadrant, and the appro- 
priate timing signals 

Contrast 

The issue of contrast is a complex subject, depending mostly 
on the particular liquid-crystal material s properties, the operating 
temperature, and the number of rows being multiplexed Multi- 
plexing is used because direct drive would require an impractical 
number of interconnects. Each row line is selected while the 
representative voltages for on and off dots are set up on the 
column lines Rows not being selected are biased to a back- 
ground voltage. Overall, the more rows, the smaller the difference 
in rms voltage between selected and nonselected pixels for a 
given maximum bias. Since the alignment of the LC helix is per- 
turbed relative to the amount of rms potential it experiences, the 
difference between on and oft pixels, the contrast, is limited by 
the multiplexing and peak voltages of the drivers. Contrast is 
also closely linked to viewing angle, and a critical specification 
for readability relates these two factors 

The LCD's glass is separated into top and bottom sectors to 
reduce the number of rows being multiplexed by a factor of two 
Each of these sections is subdivided to form four quadrants 
Column lines enter from both the top and the bottom of the panel, 
and are driven by four 240-bH parallel-load CMOS latches whose 
outputs are capable of an 18V swing The row lines are scanned 
in a similar manner to a keyboard scan, with the top and bottom 
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refresh occurring simultaneously By keeping the refresh rate 
low. less power ,s used, EMI is reduced, and an acceptable level 
of flicker is achieved 

At the time of release of The Portable m May 1984 only 64-way 
multiplexed LCDs could be produced with acceptable contrast 
By mic 1985 the 100-way multiplexed panel was used m the 
Portable Plus with improved contrast and viewing angle Better 



contrast will be achieved with the development of better LC ma- 
terials and CMOS drive's with greater voltage swings 



Glenn Adler 

Development Engineer 
Portable Computet Division 
(now with Beckman Instruments) 



cessor that was developed by Harris Semiconductor. 

The Portable contains 272K bytes of CMOS static RAM 
and 384K bytes of ROM. The Portable Plus contains less 
memory in the base unit (128K bytes of RAM and 192K 
bytes of ROM), but is currently expandable via plug-in 
cards to 1.28M bytes of RAM or 1.5M bytes of ROM. 

The Portable Plus is designed for software compatibility 
with The Portable and to accommodate plug-in expansion. 
System RAM starts in memory space at address 00000,,, 
and grows upward. Display memory begins at address 
80000 Ifl . and the system ROMs reside in the upper ad- 
dresses. A 256K-byte swap space is used to swap in a pair 
of one-megabit application ROMs completely when needed. 
The I/O space allocation of built-in devices is compatible 
with The Portable. The 32K bytes of I/O space not used in 
The Portable is used in the Portable Plus for its plug-in 
drawers. (For details about the memory system and its man- 
agement, see the article on page 21.) 

CPU 

The 80C86 processor operates at a 5.333-MHz clock rate, 
which is about 12% faster than processors used in typical 
personal computers. This, combined with the increased 
efficiency of the 80C86 16-bit bus. lets The Portable and 
Portable Plus operate almost twice as fast as the standard 
8088-based computer. The 5.33-MHz clock rate was chosen 
to provide increased processing power in addition to saving 
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Fig. 2. Block diagram of the hardware system lor The Porta- 
ble and Portable Plus Computers. 



precious printed circuit board area. The 82C84A clock 
generator and a 74HC393 dual binary counter form the 
clock generator circuit. The 82C84A uses a 16-MHz crystal 
to create a 5.33-MHz (33% duty cycle) clock for the 80C86 
and a 2.67-MHz (50% duty cycle) clock for peripherals. 
The 16-MHz output clocks a counter in the 74HC393. creat- 
ing 1. 2. 4, and 8-MHz signals. To use all of the available 
space, the unused half of the 74HC393 is pressed into ser- 
vice as a counter for wait state insertion. In The Portable, 
the lower 512K bytes of memory space are allocated to 
system RAM. and run with no wait states. I/O devices re- 
quiring longer access times have one wait state to pull the 
open drain ready line low to insert additional 80C86 wait 
states. 

The current drawn by the B0C86 is low compared to an 
NMOS part, but is still too high to leave running all the 
time. The Portable and Portable Plus contain a second mi- 
crocomputer called the peripheral processor unit (PPU) 
that controls the system when the 80C86 is turned off. This 
processor (an MC146805) typically draws 1% of the current 
of the main processor and is left running all the time. 

PPU and Battery Supply 

The peripheral processor unit actually operates the com- 
puter because it controls the switches that power the rest 
of the system. The PPU contains a timer that is used to 
provide a real-time clock for the system. It also provides 
for time-zone conversions and alarms. Because it has a 
clock and controls the power, the PPU can wake the system 
up at a predetermined time to run an MS-DOS program 
and, when finished, it can then put the computer back to 
sleep. It monitors all the interrupt lines so that if an inter- 
rupt occurs while the main CPU is turned off. it can power 
up the CPU to service the interrupt. For example, the com- 
puter can be awakened by an incoming telephone call and 
can be programmed to answer it. 

A fuel gauge value that represents the percentage of 
charge left in the battery is computed by the PPU using 
configuration data supplied by the main CPU and then 
displayed in the main menu screen of the computer's built- 
in Personal Applications Manager. The PPU knows what 
sections of the computer are active and drawing current. 
It also receives a signal from the charging circuit that indi- 
cates when the battery is being charged. It uses this data 
to calculate the amount of charge available in the battery 
at any time. Although the accuracy of this value will de- 
crease as the battery ages, the only other way to determine 
the charge of the battery is to meusure the terminal voltage, 
a method that would only give a result within 20% of the 
true value. 

The PPU controls the charging circuit and can switch it 
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into a low-charge-rate, or float, mode when the batteries 
are fully charged. This prevents battery damage if the user 
leaves the computer plugged in constantly. 

The battery charger is a current-limited, precision voltage 
regulated power supply. The output voltage is either 7V 
or 7.5V as selected by the PPU. As the battery nears full 
charge, it accepts less current. To speed up the final stage 
of charging, the charging voltage is switched from 7V to 
7.5V for a period of time. This also ensures that each cell 
is fully charged. Thereafter, the supply remains at 7V for 
as long as the charger is plugged in. 

One of the characteristics of the sealed lead acid batteries 
used in HP's portable computers is that optimum battery 
life is achieved by charging them whenever possible, using 
a charging voltage of 2.32V to 2.35 volts per cell. The op- 
timum voltage is temperature dependent. Hence, the 
charger circuit is temperature-compensated to produce the 
optimum voltage over the range of - 20°C to +60°C. 

After discharge, each battery cell is slightly overcharged 
as mentioned above to ensure cell equalization. The PPU 
tailors the overcharge cycle to match the depth of cell dis- 
charge. The charger control circuit also determines if there 
is a shorted cell Iwhich can happen if the battery is exces- 
sively discharged). If so, the main charger is turned off to 
protect the regulator. 

One weakness of a lead acid battery is that it can be 
damaged if it is deeply discharged. This occurs if a battery 
is discharged to significantly beyond its normal capacity. 
To prevent this, the power switch is operated by the PPU. 
The PPU monitors the battery voltage to see if the battery 
charge is too low to power the rest of the system. If so, it 
refuses to turn on the 80C86 CPU. This prevents the user 
from running the battery down to a level where it may 
sustain damage. In such a case, the batteries still have 
enough charge to preserve memory for more than a week 
so the user can continue with the same application and 
data immediately after connecting the charger supply. 

A single wall-mounted transformer serves as both an ac 
adapter and a power supply for the charging circuitry. The 
switch from ac to battery power is all electronic, which 
gives the HP portable computer family several advantages. 
If a user unplugs the transformer from the wall outlet (or 
if the power should fail), the computer instantly starts using 
its battery for power. Some portable computers use a 
mechanical switch in the charger plug and they lose power 
when this happens. 

Battery Choice 

Choosing a battery was a significant design activity. Non- 
rechargeable batteries were rejected as a source because 
their life would be intolerably short (7 to 13 weeks for 
alkaline D cells, depending on the number of cells used). 
The package is large enough to use batteries the size of D 
cells, however, so the choice was between three sealed lead 
acid cells or five nickel-cadmium (NiCd) cells. Size and 
weight per watt hour in the two chemistries are essentially 
the same. NiCd cells have several well-known problems: 
short lifetime of typically two years (the average data sheet 
is exceedingly optimistic), near impossibility of building 
an optimum charger, reduced lifetime caused by use of sim- 
ple chargers, electrolyte leakage from dead cells. larger inter- 



nal current leakage, and memory (inability to produce large 
energy cycles after being repeatedly used in small energy 
cycles). Lead acid batteries suffer from none of these prob- 
lems. On the other hand, lead acid batteries are often dam- 
aged, sometimes ruined if they are run intoanoverdischarged 
state. This is easily avoided with a low-battery cutout as 
discussed earlier. Finally, lead acid batteries are less expen- 
sive. 

The low internal leakage of the lead acid batteries pro- 
vides a margin of safety for the user's data which simply 
is not available with other simple portable power systems. 
At room temperature, a fully charged lead acid battery will 
maintain memory (without other use) for nearly a year, 
liven if the computer is run until the low-battery-charge 
cutoff algorithm turns it off (which leaves about 10% of 
the battery charge), the memory will typically be main- 
tained for a month at room temperature. Even at elevated 
temperatures, the lead acid battery has a relatively low 
self-discharge rate. At a constant temperature of 50°C. a fully 
charged battery will maintain memory for over four months. 
By comparison, a fully charged NiCd battery with no load 
at all will self-discharge at room temperature in about three 
months. 

Power Supply 

Since the battery supply selected always exceeds 5V and 
most of the electronics uses a regulated 5V. a simple linear 
regulator is used for the power supply. Regulators that were 
commercially available when The Portable was designed 
used a few milliamperes internally even under no-load 
conditions. It makes little sense to design a computer that 
only requires 0.25 mA in sleep mode if the regulator re- 
quires 2 mA at the same time. Newer regulator ICs have 
since been introduced that draw only about 50 itA. which 
is more acceptable. The no-load current of the custom reg- 
ulator in The Portable is 12 itA for the reference, 6 itA for 
the feedback resistors (which you also need for the new IC 
regulators), and 3 fiA internally in the regulator. 

The display needs a -7V to -12V regulated supply that 
can be varied under control of the PPU. This was done 
with a feedforward, inverting regulating converter, an ap- 
proach not commonly used for regulation. Unless a lot of 
second-order effects are considered in the design, the load 
regulation is poor. In this case, since the display looks like 
a constant resistance, the load regulation is not so important 
and supply stability is easily obtained since there is no 
feedback. The contrast ratio of the LCD screen is adjusted 
by varying the negative voltage. The supply design provides 
an output voltage that is constant to well within 1% over 
the range of the input voltage (5.5V to 7.5V) and to within 
2% over a load current variation of at least 5%. 

LCD Controller 

A custom IC to control the liquid-crystal display was 
designed for both The Portable and the Portable Plus. Two 
factors drove the decision to design a custom chip in The 
Portable. First, no existing controllers were available that 
were compatible with the 80C86 bus. The additional cir- 
cuitry needed to integrate them into the system would have 
been too expensive in terms of printed circuit board space. 
Second, the only controllers available were in surface- 
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mount packages while all other chips in The Portable are 
in dual in-line packages (DIPs). Adding a major manufac- 
turing step for one component was undesirable. 

An LCD presents design constraints not seen with CRT 
displays. Primarily, the LCD is a truly digital display — it 
has neither horizontal nor vertical blanking periods that 
allow for CPU access of display RAM. The data flows to 
the display in an uninterrupted stream. Access to display 
RAM has to be controlled so that the LCD controller always 
has priority while the CPU sees the display RAM as a 
normal segment of its address space. 

In The Portable, an additional packaging constraint is in 
force. Namely, as mentioned above, manufacturing consid- 
erations required that the controller be packaged in a stan- 
dard plastic DIP configuration. This restricts the pin count 
to a maximum of 48. In addition, the display RAM had to 
be made up of the same 8Kx 8-bit CMOS static RAM parts 
used elsewhere in The Portable to meet low-power require- 
ments. This restriction prevented multiplexing of address 
and data to the RAM since these parts have separate address 
and data lines. 

These constraints resulted in the LCD controller and the 
display RAM being placed on a private bus that can be 
used- by either the CPU or the LCD controller. This private 
bus is isolated from the system bus by buffers under the 
control of the LCD controller. Data fetches by the LCD 
controller are arranged to leave windows during which the 
CPU can access the display RAM or the controller registers 
without interrupting data flow to the display. Any CPU 
access to either the display RAM or the controller registers 
causes the controller to halt the CPU by immediately pull- 
ing the ready line low. The controller then uses CPU access 
windows as available to move data between the system bus 
and either the display RAM or the control registers as 
appropriate. When the data transfer is complete, the ready 
line is released and the CPU cycle proceeds normally. In 
this way. display accesses are no different from conven- 
tional access methods as viewed by the software, despite 
the need for the CPU to wail for the next window of oppor- 
tunity. The LCD controller also converts any 16-bit memory 
accesses from the CPU into two 8-bit accesses for the RAM. 

Experience with the hybrid RAM in The Portable gave 
enough confidence in the hybrid technology to use it for 
the LCD controller in the Portable Plus (see article on page 
25). With the limitation of 48 pads on the controller chip 
eliminated, the private bus used in The Portable was moved 
onto the controller chip. The result is a 77-pad 1C with two 
complete 16-bit. nonmultiplexed bus Interfaces — one inter- 
face for the 80C86 CPU and one interface between the con- 
troller and the display RAM. With the Portable Plus' two 
display RAM chips on the same hybrid substrate as the 
controller, the entire display control function is placed in 
a 48-pin DIP configuration package with enough otherwise 
unused pins to allow some of the Portable Plus' system 
glue logic to be implemented on the LCD controller chip, 
The system of holding off the CPU with the ready line 
is the same in the Portable Plus as it is in The Portable. 
The LCD still must have priority in accessing display data. 

Video Interface 

When it was decided to provide a video interface for the 



Portable Plus, the machine design (both hardware and soft- 
ware) was firmly set. The principal design constraints were 
minimal hardware impact and no software impact. Thus, 
the information for the external video display is tapped 
from the data and clock lines driving the LCD panel. In 
this way. the existence of the video interface is invisible 
to the software. The drawback is that the software has no 
control of the video display independent of the LCD dis- 
play. 

The external video display normally shows a copy of 
what is on the LCD. It also has a freeze-frame feature that 
is activated manually with a pushbutton on the video inter- 
face box. In freeze-frame mode, the interface controller sim- 
ply stops refreshing its buffer RAM from the Portable Plus 
display signals. Thus, the monitor can hold one frame of 
information (frozen) while the Portable Plus proceeds with 
its normal active display. This can be useful, particularly 
in word processing or spreadsheet analysis, for comparing 
results or to double the amount of displayed information. 

Keyboard Controller 

The keyboard controller was especially designed for the 
needs of this portable computer family. It has a built-in 
sleep mode that lets it watch the keyboard for any key 
strike while consuming far less than a milliwatt of power. 
The keyboard controller can wake up the system with an 
interrupt and then read the keyboard to see what key is 
pressed. This allows the system to be started with the touch 
of a key. The keyboard controller does not scan the matrix 
by strobing every line individually, but rather strobes all 
the rows at once and then all the columns. The rows are 
strobed low and the columns read to see if a key is pressed 
and then the columns are strobed high and the rows are 
read. This method will detect any key closure on the matrix 
but consumes very little power until a key is struck. 

Plug-In Memory 

The Portable is configured with over one-quarter mega- 
byte of RAM and 384K bytes of ROM. One of the chief 
design goals of the Portable Plus was to increase this capac- 
ity while giving the user the ability to customize the 
machine's configuration. To do this, the Portable Plus is 
designed with two plug-in memory slots. 

These drawer slots provide a means for customizing the 
hardware configuration according to the specific needs of 
various sectors of the computer marketplace. The docu- 
mented open architecture of the Portable Plus gives inde- 
pendent hardware vendors easy access to the machine, 
opening opportunities for market expansion beyond those 
Hewlett-Packard is formally pursuing. The second general 
enhancement made possible by the drawer slots is the abil- 
ity to expand the basic functionality of the machine. Both 
RAM and ROM can be added to the Portable Plus through 
these slots. 

The ability to expand the basic functionality of a machine 
is especially important when designing a product that is 
at the leading edge of packaging technology. The physical 
constraints imposed by the packaging density of integrated 
circuitry (especially memory) result in a product whose 
basic functionality may be marginal in some applications. 
Expansion drawers provide an opportunity for improving 
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Low-Power Modes for Portable Computers 



One of the first discoveries thai a new user makes about Hew- 
lett-Packard's portable computers, The Portable and Portable 
Plus, is that there is no ON/OFF switch Each computer draws its 
power Irom a battery pack that will maintain the system for up 
to 20 hours under normal operating conditions Two low-power 
modes are implemented to conserve battery power powersave 
mode and sleep mode The powersave mode is achieved through 
a CPU halt instruction Sleep mode is similar to an off state since 
the display is turned off and many of the internal circuits are 
powered down These low-power modes are controlled by a 
single-chip microcomputer known as the peripheral processor 
unit (PPU). 

Powersave Mode 

If an application frequently checks for keyboard activity, battery 
life can be improved by about 44% by allowing the system to 
enter the low-power halt known as powersave mode. In this mode 
there are no memory accesses since the CPU is halted, and there- 
fore, the power dram is decreased. The PPU is made aware of the 
halt so that it can ad|ust ils power consumption calculations to 
account for the reduced system activity. The result of these cal- 
culations is displayed in the mam PAM (Personal Applications 
Manager) screen as a percentage indicating the level of remain- 
ing battery charge. The CPU remains halted until a hardware 
interrupt occurs. 

The powersave mode is implemented by the keyboard driver 
and accessed through either the console driver or the BIOS 
interrupt hexadecimal 16. There are two situations (Fig. 1) that 
can put the system into powersave mode. First, if the keyboard 
driver is asked to return a key input and the keyboard buffer is 
empty, the system halts and waits until a key input becomes 
available. The halt state Is terminated when a hardware interrupt 
occurs. The maximum amount of time that the CPU will be halted 
is dependent on the hardware timer interrupt interval (The Port- 
able timer interrupts once per second and the Portable Plus timer 
interrupts 18 times per second) The interrupt is processed and 
the keyboard buffer is checked again to see if the CPU should 
do another halt. 

The second situation occurs when an application is expecting 
a keystroke, but rather than letting the keyboard driver wait for 
it. the application does the waiting by repetitively reading the 
keyboard input status The keyboard driver keeps count of the 
number of input status requests made in a one-second interval 
It that count reaches a set limit, the driver halts m powersave 
mode When a subsequent hardware interrupt occurs, the inter- 
rupt is processed, the status request counter is reset, and control 
is returned to the application 

The powersave mode can be disabled manually by a user in 



the PAM system configuration menu or, on the Portable Plus, it 
can be disabled programmatically by an application through the 
system service functions. In either case, the powersave mode 
is only disabled for the second situation described above The 
keyboard driver will always enter the powersave mode when a 
keyboard read request is attempted while the keyboard buffer 
is empty. 

Sleep Mode 

During sleep mode, most of the system is electrically shut 
down and the PPU is in a low-power state monitoring system 
events. The CPU, modem, LCD display, and serial and HP-IL 
interfaces are turned off Only display RAM, built-in RAM, plug-in 
RAM, keyboard hardware, and the PPU remain on Coming out 
of sleep mode, the BIOS code completely restores the system — 
the LCD displays the same information as before the sleep and 
the suspended application resumes where it left off 

There are three events that prompt the BIOS code to put the 
computer to sleep First, the sleep interrupt is available to all 
applications to put the computer into an off state. PAM calls this 
interrupt when the OFF softkey is pressed Second, when the 
computer is on but not being used, it may eventually time out 
and go to sleep. The time-out feature is designed to help prevent 
running down the batteries when the computer has been left idle 
but not turned off Finally, if the batteries are run down to a level 
providing only questionable power to the system, the BIOS code 
forces the computer to sleep to prevent the loss of data on the 
internal RAM disc. 

The computer may go to sleep in the middle of an application. 
Once awakened, it must continue from exactly where it left off. 
The sleep routine must gather enough information from the cur- 
rent system so that once it is reset, the presleep state can be 
restored. The optional modem in the Portable Plus contains user- 
definable features that are lost when power is cut to the modem 
while sleeping. A special command is sent to the modem before 
sleeping that requests the current state of these features. The 
information is then kept in the system RAM, which remains pow- 
ered during sleep. In both The Portable and the Portable Plus, 
the HP-IL chip registers and the address of the current stack are 
read and saved to be restored upon waking 

To initiate sleep mode, a command is sent to the PPU. The 
PPU remains powered during sleep mode to maintain the real- 
time clock, calculate the current power level, and watch to see 
if the system should be brought out of sleep, it will wake up the 
system when any key is pressed, an alarm goes off, when the 
modem or serial port receives a ring interrupt, or if an interrupt 
is received from a plug-m card. 

Immediately after being reset, the CPU determines that it has 



Keyboard driver 
receives a request 
for a key 



is the keyboard 
butter empty'' 



I Yes 



Powersave halt 
until a hardware 
interrupt occurs. 



Return key 



(a) 



Keyboard driver 
receives a request 
for staius 



J 



Has the staius 
request occurred 
often enough to 
cause powersave mode? 



Yes 



Powersave halt 
until a hardware 
interrupt occurs 



No 



Return siatus 



Fig. 1. Powersave mode opera- 
lion can be triggered by situation 
(a) or (b) 
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Deen sleeping ana that ihe system must be restored rather than 
rebooted The stack is set up from the information saved m system 
RAM be'ore the reset The modem is reconfigureo ana the HP-IL 
chip status is restored The system interval timer <s restarted and 
the time displayed m the softkeys is updated Finally an interrupt 
return instruction is executed to return to the active application 

Time-Out 

Severa* factors determine whether or not the unit will time out 
The BIOS code assumes that it is safe to stop m the middle of 
an application if it has asked the keyboard dnver to return a key 
input ana is waiting If the keyboard buffer is empty, the driver 
waits a set amount of time before deciding to time out The 
application may also be waiting for a key input it it is repetitively 
reading the keyboara input status. This is determined m the same 
way as the second powersave situation described above — the 
keyboara driver counts the number of input status requests in 
one secona and waits for that count to reach a certain limit to 
time out There is a difference, however, in that any other driver 
call or I/O activity will reset the count to zero For example, a 
program in a simple loop checking keyboard status will certainly 
time oui and go to sleep, but a program that alternates between 
checking the serial port status and checking the keyboard status 
will not The computer cannot go to sleep m this case since, 
although a keystroke would wake the system up, any characters 
coming in from the serial port would be lost. 

Once it has been determined thai the application is only waiting 
for a key input, the computer makes a time-out decision (Fig 2) 
On the Portable Plus the system checks for the presence of a 
serial or modem carrier The intention is to not drop a carrier and 
lose the connection The current power level and the presence 
of a battery recharger also affects whether or not to time out 
The Ponable will not time out if the recharger is connected; the 
Portable Plus will nol time out If Ihe recharger is connected and 
the current battery level is above 80% 

Using the PAM system configuration menu, the user can man- 
ually disable the time-oul feature or change Ihe length of time 
that the system musl be idle before the lime-out occurs In the 
Portable Plus, a system service is provided to modify the rate at 
which the keyboard status calls must occur to cause a lime-oul 
This rate can be customized by an application to either prevent 
or force a lime-out 

Battery Shutdown 

When the battery charge has fallen too low to maintain a reliable 



Yes 



Is there a modem 
or serial earner'' 




I 



Is the recharger 


Yes 


plugged in' 








Invoke steep 
interrupt 




1« 



(a) 



(b) 



Fig. 2. Time-out decision process lor (a) Portable Plus and 
(b) The Portable 

system, the compuler is put to sleep. At this point, the most 
important use of the remaining power is to preserve Ihe data on 
the RAM disc by conserving all power for the system RAM The 
PPU determines that a shutdown should occur and alerts the 
CPU The computer goes to sleep and will not wake up until the 
recharger is plugged in and a key is pressed, 
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this functionality and can help prolong the life of a product. 

The Portable Plus was introduced with a RAM drawer 
and a ROM drawer. The RAM drawer is delivered from the 
factory with 128K bytes of CMOS static RAM. but is ex- 
pandable to 384K bytes in 128K-byte increments. From the 
user's point of view, this additional RAM is the same as 
the RAM built into the Portable Plus. 

The ROM drawer provides a means for the user to add 
ROM-based software to the computer. This drawer has a 
storage capacity of 1.5M bytes and supports up to twelve 
ROMs. Applications software can be designed to execute 
directly out of ROM or it can be downloaded into RAM 
before execution, as in typical disc-based packages. 

Coupled to the plug-in board space issue is the method 
of identifying and configuring the plug-in cards. The goal 
is to make the plug-ins autoconfigurable, so that all I he 
user has to do is install them. The board area limitations 



shifted this responsibility from hardware to memory man- 
agement software (see article on page 21). The mainframe 
provides a sbcteen-word region in I/O space for each plug- 
in. In this area, each plug-in has a card identification regis- 
ter and a configuration register. This allows software to 
determine system resources and configure them accord- 
ingly. To ease hardware and software designs, plug-in RAM 
increases are constrained to 128K-byte increments. 

Self-Test 

Manufacturing and serviceability are important issues in 
the design of any product. In the Portable Plus, much effort 
was put into the development of a built-in self-test. This 
is useful in isolating failing components in the factory and 
the field. It is available to customers and can be used by 
them to determine whether their unit needs service. It is 
also useful to dealers and service centers that install op- 
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tional accessories such as modems, software drawers, and 
memory drawers. The self-test can he used to verify that 
the optional hardware is properly installed before giving 
the unit to the customer. 

The tests are accessed by turning the computer off and 
then pressing the Shift, Extend char, and »8 keys simultane- 
ously. This causes the computer to boot into the self-test 
code instead of the Personal Applications Manager. The test 
code is part of the firmware stored in ROM in the machine. 
It consists of a number of different tests and each test checks 
a different block of circuitry in the unit. These include an 
LCD test, a timer test, an RS-232-C/V.24 test, a modem test, 
a ROM test, a RAM test, and a software/memory drawer test. 

A displayed menu indicates the tests available and warns 
the user of the length of time required to run the RAM test 
and the RAM portion of the software/memory drawer test. 
The user presses the appropriate softkeys and the Shift key 
to select any single test or all tests in sequence. 

When a failure is found, a message is displayed indicat- 
ing the assembly and reference designator of the failing 
part. If no failure is found, the message -ok is displayed 
when the test is completed. Pass/fail messages are also sent 
to a Thinkjet Printer if one is connected via the HP-IL port. 
This feature proved useful during the QA evaluation phase 
of the product's development. Units were placed in an 
environmental chamber and subjected to extremes of tem- 
perature and humidity while running the built-in self-test. 
Each computer was connected to a printer outside the 
chamber and the pass/fail information was recorded. 

Since the tests are available to customers, they must run 
without any external test equipment. This requirement di- 
minishes the coverage of the RS-232-C/V.24 and modem 
tests, since the interfaces to the RS-232-C line and tele- 
phone line cannot be checked without some form of plug-in 
test equipment. For this reason, the built-in tests are not 
used by HP factory and service facilities to test the RS-232-C 
port and the optional built-in modem. Instead, another set 
of tests is used that requires plug-in test equipment and 
provides a more comprehensive check of these two sec- 
tions. 

Self-test code should require a minimum number of 
working components in the system to run. Although there 
are 28 LSI circuits in the Portable Plus, only five are needed 
to run the built-in self-test. 

Mechanical Design 

The HP portable computer family is a modular computer 
family. The main computer is a completely self-contained 
package with disc drives and printers available in their 
own separate packages. This allows the portable computer 
user to reduce the system weight by taking only the com- 
ponents that are needed on a particular trip. Since most of 
the fragile mechanical devices are excluded from the main 
system, it can be designed to withstand a much more hostile 
environment. 

Portability and durability were the major design consid- 
erations throughout the mechanical development of The 
Portable and Portable Plus. The printed circuit boards were 
laid out in parallel with the plastic parts being designed 
to ensure maximum space efficiency. The system board in 
The Portable fits into the bottom case, component side 



down, and the stiffening ribs on the bottom case are placed 
around the ICs. This cooperation between printed circuit 
and mechanical design helped keep the product height 
low. Keeping the product height to a minimum was also a 
factor in choosing the keyboard design. The final selection 
uses a low-profile switch that has 75% of the travel of a 
standard key switch. 

The clamshell design not only provides portability, but 
also protects both the keyboard and the display from the 
hazards of the transport environment. A carrying case is 
included instead of a built-in handle. The carrying case 
has a shoulder strap which is often more convenient than 
a handle, and the handle on the carrying case is padded 
for comfort. 

Manufacturability. along with mechanical integrity, was 
a strong consideration in the mechanical design of both 
products. In The Portable, the printed circuit boards are 
made to mount into the bottom case, stacked onto hollow 
studs (see box on page 13) with spacers to keep the leads 
from shorting. The assembly consists of the bottom case, 
the system printed circuit board (component side down), 
a set of spacers, a copper shield for EMI (electromagnetic 
interference) and ESD (electrostatic discharge) protection, 
another set of spacers, the I/O board (component side up), 
and finally a set of nuts to clamp the assembly together. 

The display assembly consists of two plastic parts that 
snap together to form the housing around the display, the 
arms that come down to the pivot point, two brackets to 
stiffen the assembly and mount the display, miscellaneous 
spacers, latches, and springs, and the bezel and bezel cap. 
This assembly, like the bottom case assembly, is designed 
with manufacturing in mind. Most components of the as- 
sembly are stacked onto studs and then the assembly is 
held together with nuts. The bezel is held to the assembly 
by two screws hidden beneath the bezel cap. which is 
attached to the bezel with a double-sided adhesive foam 
tape. The cabling that brings power to the LCD is routed 
through one of the arms before the two plastic parts are 
snapped together. This eliminates the exposed cable com- 
mon in many competitive products. The clutches, or fric- 
tion-restrained hinges, are mounted on the arms at the pivot 
point and are attached later to the top case assembly. 

The top case acts as the "hub" of the product since all 
parts connect to it. The keyboard is mounted to the top 
case to avoid alignment problems and eliminate the possi- 
bility of keys interfering with the top case surround, caus- 
ing them to stick. The mounting of the keyboard is some- 
what unusual, because it is threaded through the mounting 
tabs and then rotated into position before being tightened 
down with eight nuts. This mounting method allows the 
keyboard to be mounted in the top case without requiring 
special slides or pulls in the top case mold tooling to allow 
for the angle of the keyboard. 

The display assembly is mounted to the top case by the 
clutches, which slip over hollow studs similar to those 
used in the bottom case. Being hollow, these studs allow 
screws to come from the bottom of the top case to connect 
to the hinge cover, making that connection invisible on the 
final product. The top case and bottom case assemblies are 
then connected together by a rotating motion which en- 
gages a latch detail at the front of the unit, electrical con- 
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Hollow Studs for Package Assembly 



Loss ol lonjue has been the sub|ect ot many discussions re- 
laled to ihe use of uitrasomcally installed inserts m plastic parts 
The problem occurs because of the tendency ot plastic materials 
to delorm slowly or creep under lorce When a screw is lightened 
into an inset, the torque causes tension in the screw This tension 
is transferred trom the insert to the plastic boss into which it « 
inserted Most inserts have a holding design of opposing knurls 
or steps m the body of the msen These designs do help to hold 
the msert m but as the plastic creeps, the insert moves slightly 
releasing the tension and thus the clamping force and torque on 
the screw. 

One method used to solve this problem is to add a shoulder 
or flange to the insert and ensure that the hole in the mating pan 
is smaller than the size of the flange. This way. the insert is 
supported by the mating pan In most cases. Ihough. the mating 
pan is also plastic, and even if the insert cannot pull out (termed 
"lacking out"), the wall of the plastic mating part will creep under 
compressive forces and 'he result is the same Another cure for 
lacking out (and good standard practice) is to install the insert 
either slightly above or flush with the boss, but never below its 
surface This will prevent lacking out of the insert, but as with 
the added flange, if the mating part is plastic there will be creep 
and loss of torque 

A different concept is employed in the fastening design of The 
Portable Hollow sluds were designed to attain metal-lo-metal 
contact wherever torque and clamping loads are critical (see 
Fig 1) Both the hollow stud and the associated female insert 
havp flanges at their mating surfaces The installed height of the 
hollow stud and female insert is toleranced so that there is a 
zprn clearance or an interference fit With this design, the tensile 
stresses are never transferred to the plastic Hence, creep does 
not come Into play and there can be no jacking out of the insert 
or compressive relaxation. 

Ihe hollow stud is designed to allow internal clearance of an 
M? r - screw and the stud's external threads are M6. The outer 
diameter of the stud seems quite large tor so small a product, 




Fig. 1. Hollow stud lastener design used in HP's portable 
computers to avoid transferring tensile stresses in fasteners 
to the plastic surrounding the fasteners 



but considering the space taken on the printed circuit board, 
one larger hole requires less room than the two smaller holes 
that would have been required, one to hold the boards and the 
other to assemble the top case to the bottom case. 

This stud design accomplishes more than one function It 
makes a good mechanical connection between the top and bottom 
cases and also provides support and mounting for the printed 
circuit boards in a space-efficient manner. 



nections are made, and the unit is completely closed by 
inserting and tightening screws from the bottom case to 
the top r:ase via the hollow studs. 

Durability 

Bulb The Portable and the Portable Plus are tested to HP's 
Class specifications. Several design iterations and close 
cooperation with the clutch manufacturer resulted in 
clutches that remain within the specified torque range for 
30.000 cycles, The key switches were cycled 10 million 
times and the latch and spring assemblies were cycled 
50,000 times. The units withstood step drops, on ail six 
facps. at six-inch increments up to 24 inches. Some units 
were still functional after drops up to 42 inches, but the 
abuse they had seen was cosmetically quite evident- The 
main problem in the Portable Plus was breakage of its LCD. 
The bigger display size in the Portable Plus posed problems 
mil seen in The Portable. The support of the display was 
improved by padding and cushioning added by the vendor 
within the display itself and arlditional cushions and bum- 
pers added to the assembly on our production line. These 



changes made surviving the required drop height of 24 
inches attainable. 
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I/O and Data Communications in Portable 
Computers 



by Andrew W. Davidson and Harold B. Noyes 



ONE OF THE MAJOR FEATURES of The Portable 
and the Portable Plus Computers is the extensive 
Input/output capabilities that are built into each 
machine: specifically, the RS-232-C/V.24. HP-IL (Hewlett- 
Packard Interface Loop'), and modem interfaces. 

Why I/O? 

In the world of portable computing, it is assumed that 
people would want to carry the capabilities of a desktop 
personal computer with them to most places they go — be 
it home, office, car. bus, airplane, business trip, or pleasure 
cruise. They would create documents, access data bases, 
comunicate with the home office, and exchange informa- 
tion (files) with other computer users. It is reasonable to 
assume that the users would occasionally be away from ac 
power sources for a significant length of time (up to eight 
hours for a transatlantic flight or up to 18 hours for a trans- 
pacific flight) and that they would want the machine to 
run on batteries during those times. If a portable computer 
does not allow its user to operate in this manner, the 
machine becomes Jess attractive, especially when a porta- 
ble computer is usually more expensive, feature for feature, 
than a comparable desktop unit. 

The question thus changes from "Why I/O?" to "What 
I/O can be included considering battery life, small size, 
and the technologies currently available?" 

I/O Selection 

As a result of these types of issues, the selection of the 
types of I/O included in HP's portable computer family 
was based on four major factors: power, industry standards, 
physical size, and ease of use. 

Power. The power consumption of the system was a major 
design concern and some of the major consumers of the 
system power are the I/O interfaces. For systems based on 
CMOS ICs. the power consumed by the system is directly 
proportional to the speed of the system. When applied to 
I/O interfaces, this means that the faster the interface oper- 
ates, the more power it requires. Because of this relation- 
ship between speed and power consumption, several at- 
tractive interfaces had to be eliminated as candidates. 
These included the HP-IB (IEEE 488/IEC 625). Ethernet, 
and other local area networks. 
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Industry standards. By definition, a portable computer is 
going to be moving around, and consequently is likely to 
encounter a variety of different computers and peripherals 
that it needs to talk to. The ability to communicate via 
industry standards is a must. 

Physical size. The word portable has become a computer 
industry buzzword, the definition of which has become 
very cloudy. The assumption made at HP's Portable Com- 
puter Division is that a portable computer user would want 
to carry the machine and at least one other bag while running 
through Chicago's O'Hare International Airport to catch the 
next flight. Even more important, the user shouldn't have to 
go into endurance training to do it (at least not because of 
the portable computer). Hence, the physical size and weight 
of a portable computer become very important design pa- 
rameters. The space required for the I/O interfaces (printed 
circuit board space as well as the space needed to bring 
the I/O connector to the outside world) is a significant 
factor. 

Ease of use. People who travel tend to be in a hurry. If they 
need special tools and/or lots of time to connect or discon- 
nect the I/O interface, it becomes a significant inconveni- 
ence. All of the interfaces chosen for The Portable and The 
Portable Plus can be connected and running or discon- 
nected and put away with very little time and effort. 

The Portable Modem 

There are two main types of applications for The Port- 
able's modem. One is subscription to the various dial-up 
personal or financial computer services that are becoming 
more available. The other is remote communication with 
host computers or other personal computers. In both of 
these applications The Portable communicates with a 
modem at the other end that is generally not made by 
Hewlett-Packard. The Portable's modem must therefore be 
able to communicate with industry standard modems. In 
the U.S.A., these standards are Bell 103 (300 baud) and 
Bell 212 (300/1200 baud). The Bell 212 standard is preferred 
over the Bell 103 standard because of its higher data rate. 
Other required features are that the modem be usable over 
the switched telephone network, and that tone/pulse auto- 
dial and autoanswer features be provided. 

Space constraints required that the modem design be 
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centered around a modem filter chip set purchased from 
an outside vendor. At the time The Portable's modem was 
designed, a Bell 212 chip set was not available, so Bell 103 
was selected. To avoid adding the space required by a 
dc-tc-dc converter, a design that requires only a single 5Vdc 
supply is used. This allows the modem circuit to be pow- 
ered from the existing 5Vdc regulator that supplies the 
computer's digital circuits. 

Although the modem'filter chip set can operate from a 
single 5Vdc supply, the analog signals within the modem 
must be referenced to an analog ground voltage of 2.5Vdc. 
This voltage level is generated by the modem'filter chip 
set, and provided on an output pin. This eliminates the 
need for adding discrete circuitry to generate 2.5Vdc. 

The single 5Vdc supply influences the design of the 
transmit section of the modem. A modem that provides 
DTMF (tone) dialing capability must be able to generate 
two tone signals of sufficient amplitude simultaneously at 
the telephone network interface. The assumed load imped- 
ance of the network is 600 ohms, and the distortion permit- 
ted in the transmitted tones is limited. Typical transmit 
levels for the two signals are -5 dBm and -7 dBm into 
the 600fl network. These levels correspond to voltages of 
1.23V p-p and 0.98V p-p. The two tones are of different 
frequency, so the combined waveform swings up to 1.23 
+ 0.98 = 2.21V p-p across the 600ft network. 

A typical modem is designed with a 600ft output imped- 
ance. Hence, such a modem would have to generate 
2x2.21V p-p or 4.42V p-p at the transmit operational 
amplifier. This is difficult to achieve with an op amp pow- 
ered only by 5Vdc such as the transmit op amp used in 
The Portable's modem design. Without sufficient voltage 
swing, limiting occurs and distortion is added to the DTMF 
signals. To avoid distortion. The Portable's modem uses a 
lower output impedance, roughly 475 ohms, and transmits 
the DTMF signals at lower levels (still within specifications). 

The chip set selected to implement the 300-baud modem 
and all digital circuitry within the computer is CMOS. This 
helps keep power consumption low. Some of the analog cir- 
cuitry within the modem is of the bipolar technology, how- 
ever. Where possible, low-power bipolar circuits are used 
and impedances are kept as high as possible. The total current 



used by the modem circuit is typically 10 to 15 mA. 

Since some users seldom use the modem, a firmware-ac- 
tuated power switch is included in the modem design. This 
allows the modem to be turned off even when the rest of the 
computer is on. The switch is implemented by a pnp transis- 
tor connected in series with the modem's 5Vdc supply rail. 
When the switch is off. the 5Vdc supply is disconnected 
from the modem, all node voltages within the modem decay 
to zero (ground), and power consumption of the modem is 
reduced to zero. The inclusion of this switch adds some 
complexity to the modem design, however. Some of the dig- 
ital inputs to the modem would normally be in the logic one 
state (5V) while the modern is not being used. These inputs 
are forced to logic zero (0V) by additional logic gating and 
control lines when the power switch is off. If not logically- 
forced to 0V. these input lines would actually supply power 
to the modem circuit through the input protection diodes of 
some of the modem chips, and power consumption would 
not drop off to zero. 

All modems that make direct connection to the telephone 
network must include the functionality of a hook switch. 
As in a standard telephone, the hook switch is closed to 
indicate that the modem is using the line to which it is 
connected, and opened to indicate nonuse. Many modems 
use a mechanical relay to perform this function. A mechan- 
ical relay, however, can require 10 to 100 mA at 5Vdc to 
keep its contacts in the closed position. This would be up 
to 10 times the typical power required by the rest of the 
modem. 

To avoid the power dissipation of a mechanical relay, 
an electronic relay (Fig. 1) was designed for The Portable's 
modem. This circuit consists of a full-wave bridge rectifier, 
an n-channel MOSFET. a bleed resistor, and an isolating 
dc-to-dc converter. The MOSFET and bridge rectifier act 
together as the contacts of the relay. When a suitable voltage 
is applied to its gate, the MOSFET turns on (contacts 
closed). When 0V is applied lo the gate, the MOSFET turns 
off (contacts opened). The dc-to-dc converter, under the 
logic control of the computer, generates the gate voltage 
required to turn on the MOSFET and maintains the voltage 
isolation between the computer and the relay contacts as 
required by the Federal Communications Commission 




Fig. 2. Optional HP 82983A Modem 
lor the Portable Plus Computer 



JULY 1986 HEWLETT PACKARD JOURNAL 15 



© Copr. 1949-1998 Hewlett-Packard Co. 



(U.S.A.). The computer disables operation of the dc-to-dc 
converter to turn off the MOSFET. The bleed resistor is 
included to turn off the MOSFET in a sufficiently short 
time. This electronic relay design requires much less power 
(100 fiA at 5Vdc) than a mechanical relay, because of the 
extremely low leakage current of the gate of the MOSFET 
and the high impedance of the bleed resistor. 

Another design choice is direct or acoustic connection 
to the telephone network. Direct connection through an 
RJll modular jack is best for ease of connection and discon- 
nection. Some sacrifice is associated with this choice, be- 
cause direct connection is prohibited at pay telephones by 
the Federal Communications Commission (U.S.A.) and 
some hotel telephones do not use modular telephone jacks. 
Acoustic connection, through cups which fit over the 
mouthpiece and earpiece of a telephone receiver, is gener- 
ally possible with all standard telephones. However, acous- 
tic connection is sensitive to receiver seating within the 
cups and to ambient noise and jarring. Direct connection 
does not have these problems. Also, an RJll jack is much 
smaller than two acoustic cups. The Portable's modem uses 
direct connection. 

Portable Plus Modem 

While the Bell 103 modem offered with The Portable 
was the best that could be done at the time, many users 
suggested that it would really benefit them if the modem 
could be an option and if it could be enhanced to meet the 
Bell 21 2A modem specification. The optional modem (Fig. 
2) for the Portable Plus accomplishes both goals. 

The Bell 21 2 A specification has achieved wide support 
as the de facto standard for 1 200-baud communication over 
the telephone network in the U.S.A. and Canada. The major 
data base services support the specification as well as all 
of the major American modem manufacturers. Included as 
part of the Bell 212A specification is the ability to fall back 
to 300-baud transmission using the Bell 103 standard. 

The technology available to implement the Bell 212A 
specification progressed significantly during the time The 
Portable was being developed. Shortly after The Portable 
was introduced, the first true CMOS Bell 212A chip set 
became available. Consisting of two custom CMOS ICs, a 
CMOS microprocessor, and a handful of discrete compo- 
nents, the modem developed by a third-party company 
became the first Bell 212A modem that had the potential 
of filling the requirements of a portable computer. Working 
with this company to modify their design so that it would 
better fit in the Portable Plus, we implemented a modem 
that reduced the printed circuit board space needed for a 
Bell 212A modem from approximately 80 square inches to 
approximately 20 square inches. The custom CMOS chip 
set also reduces the power requirements from approxi- 
mately two watts to approximately 0.25W. 

Circuits were also implemented that allow the entire 
modem circuitry to be turned off when the modem is not 
in use, helping to maintain the overall system battery life 
at acceptable levels. This was accomplished by using a 
power supply switch similar to that used for the Portable's 
modem. 

Direct connection through RJll modular phone plugs 
(with acoustic couplers as an option) was maintained from 



The Portable. In addition, an intelligent modem was im- 
plemented. This allows the user to communicate with and 
control the modem by using a set of commands. These 
commands are compatible with the Hayes Smartmodem'" 
1200 command set. This allows the many people that have 
had previous experience with the Hayes command set to 
feel at home when using the Portable Plus modem. 

Serial Interface 

The RS-232-C/V.24 interface is included in both machines 
because of the great variety of computers and peripherals 
that can communicate over this type of interface. Termi- 
nals, printers, plotters, and modems are among the many 
devices that can be addressed. In addition, when The Port- 
able or the Portable Plus is emulating a terminal, this inter- 
face can be used to communicate with a number of host 
computers. 

RS-232-C has long been a recognized standard for the 
U.S.. Canada, and Europe. It is also a de facto standard in 
many other parts of the world. As such, it is an extremely 
versatile interface to add to a portable computer. 

Because of limitations in fitting everything in the package 
for The Portable and Portable Plus, the connector chosen 
for the RS-232-C interface is not the 25-pin D-subminiature 
connector commonly used for RS-232-C devices. Instead, 
a 9-pin D-subminiature connector is used (Fig. 3). This 
prevented the implementation of some of the most esoteric 
signals described in the RS-232-C documents. However, 
the most common signals (including DCD, RTS, CTS, DTR, 
RING, and DSR| are implemented. To minimize the effect 
of having a 9-pin connector instead of the more common 
25-pin connector, custom cables that implement the most 
common RS-232-C configurations are available. These cables 
also have thumbscrews to facilitate the attachment of the 
cable to the computer. 




Fig. 3. The serial interlace port (left) lor The Portable and 
Portable Plus Computers uses a 9-pin D-subminiature con- 
nector instead of the standard 25-pin RS-232-C/V.24 connec- 
tor, because of space limitations. Most common RS-232-C 
signals are present and custom cables are available tor com- 
mon con/igurations Direct connection to the built-in modem 
is made using an RJll connector (right). 
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To minimize the power required, the entire interface can 
be turned off when not in use and only drives the output 
signals to approximately -7V (still meeting the specifica- 
tion) instead of the more common ±12V. 

HP-IL 

HP-IL stands for Hewlett-Packard Interface Loop, an inter- 
face designed by HP specifically for data communication 
between small, low-powered devices. 1 This interface is in- 
cluded in both the Portable and Portable Plus designs for 
easy connection to other devices. Although HP-IL cannot 
be considered an industry standard, it is a company stan- 
dard, and it is designed and documented so that electronic 
manufacturers can easily develop products that use the inter- 
face. HP-IL is modeled after the Hewlett-Packard Interface 
Bus (HP-IB/'IEEE 488/IEC 625). an industry standard. 

As an HP company standard, HP-IL fits well within the 
requirements of data communication in portable comput- 
ers. Through a single pair of connectors on its back panel, 
portable computers such as The Portable and Portable Plus 
can have access to flexible disc drives, printers, other com- 
puters, and many other devices. HP-IL allows groups of 
these devices to be connected simultaneously in a single 
loop, so that access to a device does not require a change 
of interconnect cables. Some interfaces, such as RS-232-C. 
allow connection of a computer to only a single device at 
a time. 

The availability of a custom integrated circuit 2 designed 
by Hewlett-Packard makes the HP-IL a compact interface. 
This CMOS IC. part no. 1LB3-0003. performs many HP-IL 
functions automatically. It easily interfaces through an 8-bit 
bus to a microprocessor system, In the case of The Portable 
and the Portable Plus, the 8086 microprocessor system 
around which both computers are designed provides the 
necessary microprocessor support for the HP-IL. The only 
added circuitry required for the HP-IL is the 28-pin CMOS 
IC and some discrete components. 

The CMOS HP-IL integrated circuit maximum power con- 




sumption is 5 mA at 5.5Vdc. Some of the IC"s automatic 
HP-IL functions make it possible to reduce power con- 
sumption even further by reducing microprocessor system 
activity. 

A group of devices connected via the HP-IL forms a loop 
structure. Each device has two connectors on its back panel . 
a female IN port and a male OUT port (Fig. 4). The OUT port 
of one device is connected to the IN port of the next device 
on the loop. What makes this system so easy to connect is 
that the user merely takes a device and an HP-IL cable, 
plugs either end of the cable into the port on the device 
that will accept it. takes the other end of the cable, and 
plugs it into the next device in whichever port will accept 
it. The cables are thin and pliable, so they are easily routed 
on a desk and take up little space. Cables typical of other 
computer interfaces are often thick and stiff, sometimes so 
much that moving the cable causes the computer to move. 
HP-IL cables require no retention screws and they can be 
chained together to give longer separation distances between 
devices. 

Data always passes in the same direction on the loop, 
from the source device to the destination device. Depend- 
ing on the positioning of devices, data must often pass 
through a device that is neither source nor destination. 
Such devices know that they are not destinations, so they 
merely pass any data they receive on to the next device. 
When the destination device receives data it is expecting, 
it retransmits the data back on the loop, continuing in the 
same direction. The data eventually makes it back to the 
source device. In this way. the source device can do error 
checking on data passed around the entire loop and knows 
whether the destination device receives correct data. All 
data transmitted on the loop, then, makes a complete trip 
around, no matter where the source and destination devices 
are. 
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Fig. 4. HP-IL ports (left and center) on The Portable and 
Portable Plus Computers. Also shown is the receptacle (right) 
lor the ac adapter 
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Personal Applications Manager for HP 
Portable Computers 

by Robert B. May and Alesia Duncombe 



■■fa HE PERSONAL APPLICATIONS MANAGER (PAM) 
on The Portable and Portable Plus Computers evolved 
from the original PAM for the HP 150 Touchscreen 
Computer. PAM is designed to provide a novice computer 
user access to most of the features of MS "-DOS without 
forcing the user to learn all of its various commands. PAM 
helps a user become productive immediately by presenting 
a simple display that shows which applications are cur- 
rently available in the system, and providing a simple, 
one-key method for invoking any of those programs. PAM 
also provides a file manager, which can perform several 
file maintenance functions, such as formatting discs, creat- 
ing directories, and deleting, copying, and renaming files. 

One of the most important functions of PAM is the con- 
trol of the system environment that it provides to the user. 
Using PAM, variables such as the size of system RAM. the 
current font, and the printer and data communications in- 
terfaces can be set and changed according to the needs of 
the user, in a manner that is transparent to an application 
program. This increases the flexibility of the system, and 
enhances application software by releasing it from many 
of the system and device-specific details that can tie it to 
only one system configuration. 

User Interface 

In keeping with the interface developed for the HP 150, 
PAM in The Portable and Portable Plus displays the avail- 
able application programs as a series of inverse video blocks 
on the screen (Fig. 1|. The blocks consist of two lines, each 
14 characters long. One line displays the letter identifier 
of the disc drive on which that application can be found. 
The top line of each block contains a label identifying the 
application to the user. The text of this label does not have 
to be the actual name of the program file that is invoked 
by MS-DOS, which can be rather complicated. Instead, it 
can be a word or phrase that is relevant to the user. For 



example, one of our ROM products is the PC2622 Terminal 
Emulator, which can emulate an HP 2622 terminal or a 
VT100 terminal made by Digital Equipment Corporation. 
To run this program on an MS-DOS system without PAM, 
you must type PC2622 /H to start it in HP mode. On the PAM 
screen, however, the user sees a block labeled HP Terminal, 
and can select it simply by moving the pointer to the block 
and pressing the Start Application softkey- In addition, a com- 
pany that has its employees use a standard spreadsheet 
program and a common template can hide the command 
used to start that program under a PAM block simply 
labeled Spreadsheet. 

Unlike the Touchscreen version of PAM, applications 
do not have to be explicitly installed by a utility program 
to appear on the PAM screen and be easily available to the 
user. On The Portable and Portable Plus, all disc drives 
connected lo the computers (including the internal RAM 
and ROM discs) are searched for a text file called PAM.MNU. 
This file defines the text of blocks that appear on the screen 
as well as the commands that are issued to MS-DOS when 
a block is selected. This mechanism allows a piece of soft- 
ware on a disc to become immediately accessible from 
PAM by simply placing the disc into a drive and having 
PAM read the disc. 

The Portable Plus accepts plug-in ROM modules that 
contain application programs. Each software module ap- 
pears as part of the internal ROM disc to the system, and 
can use the PAM.MNU feature to make its programs accessible 
through PAM. Since the ROM disc is always present in the 
system, any application that is installed in this manner is 
permanently accessible from the main command screen. 
This provides a powerful customization capability — a com- 
pany can place its application programs into ROMs and 
distribute them to its personnel. 
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Fig. 1. The PAM display screen 
for The Portable and Portable Plus 
Computers shows the available 
applications as a series of inverse 
video blocks. 
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System Configuration 

Another important feature of PAM is the ability to con- 
figure various parameters of the system. There are three 
main areas that can be modified through PAM: the clock, 
the data communications parameters, and the system itself, 
which encompasses such details as the partition between 
system RAM and RAM disc, control of the power saving 
features, and which physical peripheral devices are asso- 
ciated with several MS-DOS logical device names. 

Through the PAM system configuration screen (see Fig. 
2). the user can control many aspects of The Portable and 
Portable Plus. One of the most important fields is the Mem- 
oiy/Edisc partition adjustment, which allows the user to vary 
the size of the internal RAM disc. Because of the ability of 
the Portable Plus to accept additional RAM in its expansion 
slots, this adjustment allows maximum use of the RAM 
disc to make it as useful as any external disc drive. For 
example, a user who only needs one or two applications, 
but who uses several data files, might want to use the 
largest possible RAM disc to carry the data files in the 
computer without needing an external disc. Another user 
who uses a very large spreadsheet might want the maxi- 
mum system memory, with only enough RAM disc to hold 
the stored form of the spreadsheet model. 

Since battery life is very important on a portable 
machine, HP's portable computers have several built-in 
power saving features (see box on page 10). PAM allows 
the user to modify two of these features: the display time- 
out and powersave mode. Powersave mode is a state where 
the system processor halts whenever the keyboard is idle 
for a period of time. Most of the time, this is a desirable 
feature, since it reduces system power requirements by 
about 44%. For some applications, however, this mode can 
cause program execution to be sporadic. Through PAM, 
this feature can be turned on or off as needed. The display 
time-out is a timed function; if no key has been hit in a 
given number of minutes, the entire machine enters a sleep 
mode in which the display, keyboard, and data communica- 
tions ports are turned off, and the machine suspends execu- 
tion of the current process until it is awakened by an exter- 
nal interrupt. Thus, whenever the machine is left in an 
idle state for a period of time, it will automatically turn 
off, but no data will be lost, and no application program 
will be affected. PAM allows a user to select the length of 
time that will elapse before sleep mode is entered. This 



interval can be anywhere from 30 seconds to 20 minutes, 
and it can also be disabled. 

The keyboard and display can be placed in normal HP 
mode or a special alternate mode. In HP mode, the display 
uses the standard HP Roman8 font, and the function keys 
generate standard HP terminal escape sequences. When 
the alternate mode is selected, the display uses the IBM 
PC font and the keys generate IBM-style function codes. 
Through PAM. the user can select which mode the com- 
puter will operate in. This selection is transparent to the 
application, and allows many existing IBM-PC-based appli- 
cations to be run on HP's portable computers without mod- 
ification. 

Another system configuration feature is the ability to 
assign different output devices to some of the standard 
MS-DOS logical device names. In MS-DOS. there are sev- 
eral reserved device names. The PRN device is defined to 
be the system printer, the PLT device is associated with a 
plotter, and the AUX device is defined as the primary data 
communications interface. PAM allows the user to assign 
these device names to different pieces of hardware, and to 
change the definition in a manner that is invisible to a 
program. For instance, if a word processor is written so 
that it always writes to the PRN device, a user can print 
drafts on an HP-IL Thinkjet Printer until the text is satisfac- 
tory. The user can then exit to PAM. change the printer 
interface definition, and run the program again, this time 
printing a final copy of the document on an HP LaserJet 
Printer connected to the built-in RS-232-C/V.24 port. The 
same redirection can also apply to a communications pro- 
gram. If it is designed to use the AUX device for data ex- 
change, it can run through either the built-in serial port, 
the internal modem, or the HP 82164A HP-IL/RS-232-C 
Converter. This allows a user to access several different 
peripherals without the need for a specialized program 
customized for each particular device. 

Datacom Configuration 

Data communications over RS-232-C/V.24 or a modem 
usually involves setting several parameters in the interface, 
such as baud rate, number of stop bits, word length, etc. 
Often there is no simple way to change these parameters, 
which is often required when several different systems or 
devices are being accessed. PAM contains a data communi- 
cations configuration menu (Fig. 3) that allows the user to 
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Fig. 2. PAM system contiguration 
screen on the Portable Plus 
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vary the settings of the built-in serial port, the internal 
modem, and an external HP 821 64A HP-IL/RS-232-C Con- 
verter quickly and simply. In addition, in keeping with the 
need to conserve power on portable computers, the 
datacom menu shows the current power state of the internal 
RS-232-C interface and the modem. When these interfaces 
are turned on, battery consumption is increased. From this 
menu, the user can see if an application has left the power 
on to one of these devices, and can turn it off by simply 
selecting the Off menu choice in the power field for the 
appropriate interface. 

Clock Configuration 

The system clock can be set through the clock configura- 
tion menu (Fig. 4). In addition to the standard hours, min- 
utes, seconds, days, months, and years, the clock in HP's 
portable computers allows the time zone to be set. This 
provides a simple method of keeping the system clock cur- 
rent when traveling across the U.S.A. or abroad. 

PAM and Alarms 

The PPU (peripheral processor unit) chip in The Portable 
and Portable Plus allows the scheduling of interrupts at a 
given date and time in the future. PAM gives the user a 
means of accessing this feature, along with the ability to 
display a message or perform a command when an alarm 
occurs. When PAM is started, reentered, or used to change 
the clock, the internal RAM disc is searched fora file named 
PAM.ALM in the top-level directory. If this file exists, PAM 
reads it. Each line is of the form: MM/DD/YY HH:SS Text. If 
the text begins with the > character, the rest of the line is 
interpreted as an MS-DOS command to be executed when 
the alarm occurs. Otherwise, the text is displayed. 

When an alarm occurs, the system makes a warbling 
sound that continues for about ten seconds or until a key 
is pressed. If the alarm occurs while the machine is in 
PAM, the PAM alarm screen immediately appears. If the 
alarm has a text message associated with it in the PAM.ALM 
file, the message is displayed and PAM waits for a key to 
be pressed before resuming execution. Then any command 
or program associated with the alarm is executed and PAM 
is restarted when the command or program terminates. 

If the alarm occurs in an application other than PAM, 
the warbling sound is generated, but no other action is 
taken until PAM is reentered. When PAM restarts, it notes 



that an alarm has occurred, and behaves as described above. 

If an alarm occurs while the machine is in the sleep state, 
it resumes normal execution and then proceeds as de- 
scribed above. This feature is very useful for data communi- 
cations. An alarm can be scheduled late at night when 
telephone rates are discounted to invoke a program that 
uses the modem to connect to a data base on a mainframe 
computer. In this manner, a company can distribute infor- 
mation to its field personnel electronically at a lower cost 
and a faster rate than more traditional methods. 

PAM and Ringing Phones 

The internal modem or an external modem connected 
to the serial port can generate a "ring" interrupt when they 
are called by another telephone or computer. When this 
happens, The Portable and Portable Plus make a ringing 
sound to alert the user that someone is calling the computer. 
If a ring occurs while PAM is running, PAM attempts to 
execute a command file named AUTOANSR BAT. If this file 
is present on the RAM disc, it is executed. It can do anything 
a standard MS-DOS batch file is allowed to do. When it 
terminates, PAM is restarted. 

If the ring interrupt occurs when PAM is not running, 
such as during the execution of an application, the ringing 
sound occurs, but no other action is taken. If a ring interrupt 
occurs while the machine is in the sleep state, it wakes up. 
If it is in PAM, the AUTOANSR.BAT file is executed if present. 

Localization 

In the initial design of the Portable Plus, it was decided 
that native language support would be a high priority for 
the project. Hence, we invested significant effort to ensure 
that its PAM. which is the "outward face" of the computer, 
would be as easy as possible to convert from one language 
to another, with a minimal impact on the internal structure 
of the program. 

PAM on The Portable has all of its messages compiled 
within the code of the program, at several different points. 
This made conversion from F.nglish a time-consuming task, 
and meant several different versions of PAM — an English 
PAM. a German PAM, a French PAM, etc. Our objective 
for the Portable Plus was to have one version of the program 
that uses a generic message system that makes the current 
language of the machine invisible to PAM. To this end. it 
was decided to place all of the messages, softkey labels. 
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and other text strings into the system configuration ROM. 

The configuration ROM is an EPROM (erasable program- 
mable ROM) that is programmed on the assembly line to 
contain system data and the serial number for each 
machine. For localization, the EPROM is filled with the 
PAM messages and the keyboard layout for a specific coun- 
try. The system software uses the values contained in this 
ROM when possible. The keyboard driver, for example, 
defines the keyboard according to the mapping contained 
in the configuration ROM. When PAM prints a message to 
the user, it calls a system routine to display a numbered 
message from the ROM. The system then scans the EPROM 
for the text that corresponds to the desired number, and 
shows it on the screen. In this way. PAM deals with abstract 
message numbers, with the configuration ROM providing 



Fig. 4. PAM dock configuration 
screen. 

the actual text of the message in the proper language. The 
rest of the built-in software applications on the Portable 
Plus also use this mechanism to display their messages, 
making the basic machine fully localizable by simply in- 
serting the appropriate configuration ROM on the manufac- 
turing line. 
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Memory Management for Portable 
Computers 



by Mark S. Rowe 



THE PORTABLE AND PORTABLE PLUS Computers 
run under MS"-DOS 2.11. This operating system 
requires a certain amount of contiguous read/write 
memory (RAM) beginning at physical address 0. This mem- 
ory is called system memory and is managed by the operat- 
ing system. The minimum amount of system memory re- 
quired depends upon what drivers are installed and what 
applications must run. On The Portable, the system mem- 
ory size can be set to as little as 96K bytes and on I he 
Portable Plus, to as little as 80K bytes. Both machines have 
considerably more RAM than this minimum. The Portable 
has 272K bytes of RAM. The Portable Plus (with plug-in 
expansion) can have from 128K bytes to 1280K bytes with 
the current expansion options, and has an upper limit of 
over two megabytes of RAM. 



The RAM that is not assigned to system memory is or- 
ganized into a RAM disc that appears to the operating sys- 
tem as unit A: and functions identically to a mechanical 
disc from the system's point of view, Though lacking the 
capability of off-line archival storage and the ability to read 
actual discs, the RAM disc has the advantages of being 
much more durable, consuming much less power, and 
being very much faster than its mechanical counterpart. 

Part of the operating system is a block of code called the 
BIOS, which is executed when the system is initialized 
(boot up). This code determines (in addition to many other 
tasks) the amount of system memory in the machine and 
executes the program that provides the user interface. As 
with other MS-DOS machines, the BIOS code resides in 
read-only memory (ROM) and executes automatically from 
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a reset condition. However, on both The Portable and the 
Portable Plus, the user interface program (along with sev- 
eral other system files) is also stored in ROM. These system 
files are organized in a ROM disc that appears to the system 
as unit B: and is similar to the RAM disc, except thai its 
contents are predetermined and cannot be overwritten. The 
Portable Plus has the additional capability, through its ex- 
pansion ports, of allowing ROM-based applications to be 
added. These ROM-based applications appear as files on 
the ROM disc from where they can be downloaded to sys- 
tem memory and executed. These applications can also 
directly execute code out of the plug-in ROM. 

Memory Management Code 

The operations described above are handled by the mem- 
ory management code on the Portable Plus. Memory man- 
agement on The Portable is similar to that of the Portable 
Plus, but is less complex since it deals with a fixed amount 
of RAM and has no provision for handling plug-in applica- 
tion ROMs. Within the Portable Plus the memory manage- 
ment code must determine the total amount of RAM in the 
system, allocate a portion of the total RAM to system mem- 
ory, maintain the RAM disc including read, write, and 
formatting functions, identify any plug-in ROMs and main- 
tain the ROM disc, and provide utility functions to allow 
applications to execute out of ROM and directly access a 
ROM"s contents. 

When the system comes up. the memory management 
code must determine how much RAM is in the machine. 
The Portable Plus has 128K, 256K. or 512K bytes of contigu- 
ous built-in RAM beginning at address 0 in the memory 
address space. In addition, there are four logical plug-in 
ports (two in each of the two plug-in drawers). Each drawer 
can support up to eight banks of RAM (each bank contains 
128K bytes). Thus, there can be up to two megabytes of 
plug-in RAM in addition to the built-in RAM. (However. 




' 51 2K Option 

Fig. 1. Physical RAM organization. The three built-in RAM 
options lor the Portable Plus are128K. 256K. and512K bytes 



current physical constraints on the drawer size and mem- 
ory density limit this to 768K bytes in the plug-in drawers.) 

Each of the plug-in RAM banks can be independently 
enabled and disabled. In addition, each bank can be inde- 
pendently mapped into any of the eight 128K-byle parti- 
tions of the one-megabyte physical address space (unlike 
the built-in memory which is always enabled and fixed in 
the address space beginning at address 0). Enabling a RAM 
bank so that it overlays built-in RAM. the display RAM. 
another already enabled plug-in RAM bank, built-in ROM. 
or an enabled plug-in ROM bank would cause it to function 
improperly. As banks of plug-in RAM are identified, they 
are assigned to consecutive 128K partitions of the address 
space, beginning at the end of the built-in RAM until dis- 
play RAM is reached at location 80000 1B in the address 
space. This RAM in the memory space below 80000 Hi is 
referred to as low RAM and includes all banks of built-in 
RAM and the first banks of plug-in RAM to a total of four 
banks (512K bytes). Any additional plug-in RAM is referred 
to as high RAM and is assigned to the 128K-byte address 
partition beginning at address A0000 lb . Only one bank of 
high RAM can be enabled at any time. Furthermore, since 
plug-in ROMs occupy a 256K-byte partition beginning at 
address 90000 16 , a bank of high RAM cannot be enabled 
concurrently with plug-in ROM. Refer to Fig. 1 for a dia- 
gram of the physical RAM organization. 

Since system memory must reside in contiguous address 
space, only the low RAM is available for use as system 
memory: all high RAM must be part of the RAM disc- 
Access to the RAM disc is always performed by code that 
is resident in the system ROM and data transfers are always 
to or from a buffer in system memory. Therefore, it will 
never be necessary to have two banks of high RAM enabled 
simultaneously, nor will a plug-in ROM ever need to be 
enabled during a RAM disc access. 

Once all of the plug-in RAM has been identified and 
assigned to a memory partition in either low RAM or high 
RAM. the Portable Plus memory management code deter- 
mines the amount of system memory, which is sub- 
sequently reported to the operating system during boot up. 
The boundary between the system memory and RAM disc 
can be set by the user within the constraints that the bound- 
ary must be on a 4K-byte boundary, the minimum system 
memory size is 80K bytes, the minimum RAM disc size is 
4K bytes, and the maximum system memory size is 51 2K 
bytes. The boundary can be changed without altering the 
current contents of the RAM disc. The memory manage- 
ment code determines where the last used sector of RAM 
disc is and will not allow the memory partition to be moved 
past that point. A utility is provided to allow the used 
sectors to be packed into lower-numbered unused sectors 
to free up more space that can be allocated to system mem- 
ory. 

RAM Disc 

The sectors of the RAM disc (see Fig. 2) are assigned to 
physical memory beginning with the first bank of high 
RAM. Each sector contains 512 bytes of RAM. The end of 
the RAM disc (highest-numbered sectors) is in low RAM. 
Within the 512K-byte address space of low RAM, the sec- 
tors begin at the high end and proceed toward low memory. 
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Thus, the highest-numbered sector in the RAM disc is ad- 
jacent to the high end of system memory. This allows 
the boundary between RAM disc and system memory to 
be moved easily without disturbing the current contents 
of the RAM disc. The RAM disc is increased by allocating 
sectors from the high end of system memory, decreasing 
the size of system memory accordingly. System memory 
size is increased by allocating memory from the highest 
numbered sectors of the RAM disc, assuming that these 
RAM sectors are not in use. 

Although the built-in RAM is always enabled, the plug-in 
RAM is enabled and disabled under software control. RAM 
banks can contain either system memory. RAM disc mem- 
ory, or a mix of system memory in the low end of the bank 
and RAM disc in the high end of the bank. Plug-in RAM 
banks that contain only RAM disc memory remain disabled 
except when being accessed by the memory management 
software. This is a safety precaution that minimizes the 
risk of a program inadvertently overwriting the RAM disc 
memory. Since system memory must always be enabled 
when a program is executing, a bank of memory that con- 
tains both the last sector of RAM disc and the high end of 
system memory is always enabled, leaving the high sectors 
of the RAM disc vulnerable to program errors. This vulnera- 
bility can be avoided by setting the system memory boun- 
dary on a boundary of a plug-in RAM bank. In this case 
there is no RAM bank that contains both system memory 
and RAM disc sectors. Thus all RAM disc memory is left 
disabled except when being accessed by the memory man- 
agement code and cannot be inadvertently overwritten by 
a faulty program. 
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The first sector of the RAM disc is a reserved sector 
(sector 0) that contains a BIOS parameter block in the first 
24 bytes, some system information, and checksum data for 
the first 384 sectors of the RAM disc. Each sector has a 
one-byte checksum. If additional space is required for 
checksums, it is allocated in a multiple of 512 bytes above 
sector 0 in the physical memory space, Enough checksum 
space is allocated to accommodate the maximum number 
of sectors that the RAM disc can have, given the total 
amount of memory in the machine. 

The BIOS parameter block defines the structure of the 
RAM disc as seen by the operating system. Except for the 
number of sectors on the disc, the structure is fixed, given 
the amount of RAM in the machine. The sector size is 512 
bytes per sector and there is one sector per data cluster. 
The RAM disc has one reserved sector as discussed earlier, 
and one file allocation table. There are 64 entries in the 
root directory. The number of sectors on the disc is set 
during system configuration. The number of sectors in the 
file allocation table depends on the memory size. As for 
the checksum area, a sufficient number of sectors is allo- 
cated for the file allocation table to handle the largest RAM 
disc possible. Therefore, the size of the file allocation table 
will not change when increasing or decreasing the RAM 
disc size. Fig. 2 depicts the organization of the sectors 
within the RAM disc. 

When the RAM disc driver is first entered during an I/O 
operation, it enables any low RAM that may have been 
disabled, it disables any plug-in ROM to free up the swap 
space at address A0000 16 , and it enables the first bank of 
high RAM. Since the checksum space, sector 0. the file 
allocation table, and the root directory are all at the begin- 
ning of the RAM disc and use less than 128K bytes, it is 
guaranteed that all of these frequently accessed compo- 
nents will be enabled by default. If the operation requires 
access to a sector in a bank of high RAM other than the 
first bank, the RAM disc driver will disable the first bank 
of high RAM, enable the required bank, perform the speci- 
fied operation, disable the bank, and reenable the first bank 
of high RAM. After the operation is complete (including 
updating a checksum value if required), the high RAM 
bank and any low RAM banks that contain only RAM disc 
data are disabled. If a plug-in ROM was previously enabled, 
it is reenabled and the RAM disc driver exits. 

The structure and operation of the RAM disc as described 
above provides a fast, flexible, and reliable scheme for im- 
plementing a disc-based operating system on a portable 
computer without a mechanical disc drive. 

ROM Disc 

In addition to the ROM-based BIOS software, the Portable 
Plus has about 100K bytes of system software that is built 
into a ROM disc. This software appears to the operating 
system to reside in a subdirectory of the B: disc unit. Fur- 
thermore, the expansion ports on the Portable Plus allow 
the user to plug in application ROMs that will also appear 
to the operating system as files on subdirectories of the B: 
disc unit (a distinct subdirectory for each plug-in ROM). 
Unlike the RAM disc, where each 512-byte sector is rep- 
resented by 512 bytes of RAM somewhere in the machine, 
many of the ROM disc sectors do not correspond to any 
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existing memory and are generated on the fly when re- 
quested from the various internal tables and parameters 
that are set up when the system is initialized. 

When a sector of the ROM disc is requested, the ROM 
disc driver first determines what type of sector is being 
requested. From the point of view of the ROM disc driver, 
there are six different types of sectors in the ROM disc (see 
Fig. 3). The type of sector can be determined from the sector 
number and each type invokes a unique software routine 
to extract the appropriate data and construct the sector in 
the specified buffer. If sector 0 is requested, the ROM disc 
driver fills the first 24 bytes of the destination buffer with 
fixed data from a table in ROM (this data includes the BIOS 
parameter block for the ROM disc). The remaining 488 
bytes of the sector are set to zero in the buffer. 

If the requested sector number is 1 through 0C,„. then 
the sector is part of the file allocation table. Sector 1 is 
special in that it contains the special media byte entry at 
the start of the file allocation table and includes ihe table's 
entries forthe sixteen root subdirectory files and the system 
files in addition to some of the entries in the first plug-in 
ROM. All of the other file allocation table sectors contain 
entries for plug-in ROM files. The root subdirectories are 
each one cluster long so the file allocation table entries are 
end-of-file entries (OFFF 10 ). The entries for the system files 
are computed from a table in ROM. The file allocation table 
entries for files in plug-in ROMs are computed from the 
values in the file allocation table of the plug-in ROM. Since 
each plug-in ROM is mapped into an explicit 512-sector 
range of the ROM disc, the file allocation table entries 
returned by the ROM disc driver are at a known offset from 
the values present in the plug-in ROMs themselves. From 
the particular sector requested, the ROM disc driver can 
determine what range of table entries are required and re- 
turn the correct values on the fly. 

If the requested sector is number 0D 1fi , then the root 
directory is being requested. The 512 bytes in the root 
directory sector contains sixteen 32-byte file directory en- 
tries. The first entry is for the BIN subdirectory of the ROM 
disc, which is always present and provides the path for 
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accessing the system files. Its fixed data is extracted from 
the system ROM. The remaining fifteen directory entries 
are for plug-in application ROMs. Each of the fifteen pos- 
sible plug-in ROM banks defines a subdirectory entry in 
the root directory of the ROM disc. The data for the plug-in 
ROM entries is computed from special data within the first 
sector of the plug-in together with the ordering of the plug- 
in ROMs in the expansion ports. The root directory sector 
is created on the fly when accessed. 

If sector number 0E,„ through 2D 16 is requested, then a 
sector of one of the root subdirectories is being accessed. 
Each of these subdirectories is two sectors long. Sectors 
0E 16 and 0F lf , are the sectors of the BIN subdirectory. The 
data for these sectors is computed from a table in the system 
ROM. The other thirty sectors (10,,, through 213 ,„) are sub- 
directory sectors for the plug-in ROMs. The data for these 
sectors is contained in the root directory space of the cor- 
responding plug-in ROM. Since the file entries in the plug- 
in root directory describe the starting cluster for each file 
relative to the start of the plug-in ROM. the ROM disc 
driver must modify each entry as it is copied out to map 
it relative to the start of the ROM disc. This mapping is 
dependent upon the ordering of the plug-in ROMs. The 
only other modification necessary is that subdirectory files 
contain dummy entries to link to the parent directory and 
the current directory. Since these entries are not present 
in the plug-in root directory, they are created on the fly 
when the directory sector is accessed. The data required 
for these entries is contained in special fields in sector 0 
of the plug-in ROM. 

A request for a sector number in the range from 2E 1B to 
1E9 16 will access a sector of the system files. The data for 
these files is present in the system ROM. The address of 
the requested data is computed from a table also in system 
ROM. 

Requesting a sector number from lEA 16 to lFE9 lfi access- 
es a sector from a plug-in ROM. Each of the fifteen possible 
plug-in ROM banks is allocated 512 sectors of the ROM 
disc. Thus the first plug-in ROM occupies sectors 1EA,,, 
through 3E9,,,, the second plug-in ROM occupies sectors 
3EA 16 through 5E9, 6 , and so forth. The sector allocation 
is independent of the actual size of the ROM. Sectors 
beyond the defined bounds of the plug-in ROM return un- 
defined data. All data in the plug-in ROM memory is mapped 
into some sector of the ROM disc. This includes the boot 
sector, the plug-in file allocation table, the root directory, 
and any ROM-executable code. However, these sectors are 
in general marked as available (unused) sectors in the file 
allocation table of the ROM disc and will therefore not be 
accessed by the operating system since the ROM disc is 
read-only. 

The sectors within a plug-in ROM are part of the file 
structure of the ROM disc. These sectors belong either to 
a normal file or to a subdirectory in the plug-in ROM. One 
constraint on the contents of plug-in ROMs is that all sec- 
tors of subdirectory files must occur in the ROM before 
any of the normal file sectors. The boundary between the 
subdirectories and the normal files is specified by a special 
field in sector 0 of the plug-in ROM. This allows the ROM 
disc driver to determine whether the requested sector is a 
subdirectory sector or not. This distinction is important 
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since subdirectory files are composed of file entries that 
contain a value specifying the starting cluster number. 
Within the plug-in ROM all starting cluster numbers are 
specified relative to the start of the ROM itself. When these 
values are read from the ROM disc they must be mapped 
into the appropriate cluster number within the plug-in s 
sector space. Sectors from normal files in a plug-in are 
transferred without any modification. 

This implementation of the ROM disc driver allows effi- 
cient use of the system ROM space while allowing the 
disc-oriented operating system to run unaltered. The im- 
plementation also accommodates plug-in ROMs to allow 
user application files to be incorporated into a ROM or 
EPROM in a fairly straightforward manner (see article on 
page 28). The plug-in ROM contents are incorporated into 
the ROM disc and made accessible io the operating system 
automatically by the ROM disc driver. 

Plug-In ROM 

In addition to application files, a plug-in ROM may con- 
tain software that is intended to be executed directly out 
of the ROM rather than being downloaded into system 
memory first as is required of program files. This feature 
slightly reduces the time necessary to run a program, but 
more important, it can greatly reduce the amount of system 
memory required to execute the application, thus allowing 



more memory to be used for program data or a larger RAM 
disc. 

Two system routines are provided to allow an application 
to access code or data in a plug-in ROM directly. The first 
routine allows a program to enable a plug-in ROM. Once 
enabled, a program can directly access data in that ROM. 
The memory management code automatically handles 
memory swapping when accessing RAM disc or invoking 
ROM executable code in another plug-in ROM. The second 
routine allows a program to execute code in plug-in ROMs 
directly. The routine disables any currently enabled mem- 
ory bank (plug-in ROM or high RAM), enables the specified 
plug-in ROM. and transfers control to the specified target 
location (relative to the start of the ROM). A return instruc- 
tion will then exit back through the memory management 
code which then restores the originally enabled memory. 
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A Hybrid Solution for a 25-Line LCD 
Controller 



by Glenn J. Adler 



UPGRADING TO A 25-LINE liquid-crystal display for 
the Portable Plus required a redesign of the 16-line 
controller used in the earlier HP 1 10 Compuler, The 
Portable. Because of the larger display size, even if the old 
controller could have been reprogrammed, the refresh rale 
required by the larger LCD for flicker-free operation could 
not be met. Hence, the designers decided to do a fast turn- 
around design which leveraged the architecture of the ear- 
lier 16-line custom controller. 

The objective of the LCD controller is to regulate screen 
refresh while allowing the CPU to access screen memory 
for character placement. To support a full screen of graphics, 
it is necessary to have more memory than the single 64K-bit 
static RAM used in The Portable. Therefore, two such RAMs 
are used in the Portable Plus. 

Features 

While allowing the CPU access to screen memory without 
any additional circuitry, the Portable Plus LCD controller 
regulates screen update independent of the CPU without re- 



quiring any additional circuitry in this function. When put 
in sleep mode, the controller draws a maximum of 10 /xA 
at 3V. while actively retaining the contents of its memory. 

With 128K bits of memory the controller supports 1.25 
pages of 200x480-pixel graphics displays and 2.5 pages of 
25 lines of alphanumeric data, along with three indepen- 
dent programmable fonts. 

The most significant feature of this controller is its ability 
to lock lines of alphanumeric display forsoftkey definition. 
This is handled solely in hardware through programming 
of an internal PLA (programmable logic array). The user 
need only write the desired number of rows of memory 
lock into the status register, and the controller will place 
these rows, starting al Ihe top of RAM, at the bottom of the 
screen. It is the programmer's responsibility to point the 
top-of-page around these rows so as not to show redundant 
information on the screen. This feature makes scrolling 8 
simple algorithm, even when softkeys are being used. All 
that need be done is to increment the top-of-page register. 
The display RAM is treated as a continuous cylinder. Point- 
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ing the top-of-page to the bottom of RAM will wrap the 
display around back to the top of RAM. 

In graphics mode, the graphics bits are acquired in a 
single fetch. A single PLA cycle acquires screen data in 
groups of four bytes, one for each quadrant of the display. 
In the case of alphanumeric characters, the byte is modified 
by either inversion or blanking, dependent upon the attri- 
butes and whether there is a cursor present. In both alpha 
and graphics modes there are dead periods when the screen 
RAM is not being accessed. These periods are when the 
CPU is granted access to display memory. The CPU can 
asynchronously request access by strobing the CSM line, 
but the controller will always hold the ready signal low 
until there is a dead cycle. With a 5-MHz input clock, the 
time allowed for one RAM read is 400 ns, requiring a RAM 
with a 150-ns access time. 

The display interface consists of four dot outputs and 
four timing signals. The dot outputs are shifted out serially 
with their values determined by the data fetched from 
RAM. The clock signals are generated directly from outputs 
of the PLA. The dot clock's falling edge latches a bit of 
data into each of the LCD panel's four shifters. The row 
clock shifts the value of the panel's shifters down into its 
column drivers. The frame clock strobes at the start of a 
new frame, and resets the row scan back to row zero. The 
fourth clock is a bias signal which changes the polarity of 
the voltage sent out on the row and column lines. This bias 
signal is necessary to prevent damaging effects on the liq- 
uid-crystal material that might occur if a net dc voltage 
were allowed to build up. Thus, each time a pixel is re- 
freshed, the bias voltage remains constant, but its polarity 
is reversed. 

The PPU interface is activated by accessing the I/O space 
belonging to the PPU shifter. The system will generate a 
CSPPU signal and in the case of a write, will parallel-load 
a byte of data to be transmitted to the peripheral processor. 
This write also causes the serial interface to the PPU to be 
driven high. By polling this pin, the PPU knows data is 
available and begins to drive the serial shifters' clock pin. 
When the PPU wants the CPU to read the communication 
register, an interrupt is generated and a byte is read after 
being shifted serially out of the PPU. 

Packaging and Testing 

To minimize the pin count, the controller is placed di- 
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Display 



Fig. 1. Block diagram ol Portable Plus LCD controller 



rectly on the CPU's demultiplexed address/data bus. Even 
with this reduction of pins in the CPU interface, the RAM 
circuit requires too many additional pins to package the 
chip in a conventional 48-lead dual-in-line package. There- 
fore, it was decided in the interest of conserving board 
space (see Fig. 2) and minimizing small parts count to 
mount both the controller and the RAM chips inside a 
ceramic hybrid package. Once this decision was made, pin 
constraints still dictated that the hybrid be packaged in a 
48-lead package, but this left several pins unused. Since 
the package was already on the CPU bus, a logical use for 
the additional pins was the interface to the peripheral pro- 
cessing unit (PPU). This serial-load-parallel-out. parallel- 
load-serial-out shifter was included on the LCD controller 
chip at the expense of four extra pads. 

The LCD controller was laid out on a CAD workstation 
according to design rules specified for the 3.5-/im CMOS 
technology fabricated in our in-house integrated circuit 
facility. Special care was used to ensure that the design 
was created free of dynamic nodes (except for the PLAs) 
to minimize the power used by the chip. Logic verification 
was done using an HP 9000 Computer system and a custom 
toolset. The test program was constructed directly from 
test vectors on the logic simulator using a conversion pro- 
gram provided by the tools group. It was necessary to gen- 
erate two different tests, one for the chip and one for the 
hybrid, that tested both the controller and the memory 
without access to many of the controller's pads. 

The layout of the ceramic hybrid was closely supervised 
to reduce the possibility of crosstalk. Chip capacitors are 
mounted inside the package to decouple the supply of each 
chip separately and reduce any noise. The package is sealed 
with a ceramic lid for environmental protection. 

The package is dynamically burned-in to screen infant 
mortality RAM failures, since the chips are purchased only 
after being functionally tested. The first chips showed only 
one bug, which was easily remedied through the removal 
of five rectangles in the PLA. These rectangles were etched 
off the mask, and parts then appeared to function correctly. 
Only upon margin rating fast and slow lots on the produc- 
tion tester did a problem arise. Fast parts exhibited a fight 
on the internal bus. Both these problems were solved with 
only a two-mask design turnaround. 

EMI was a problem with the 16-line controller for The 
Portable. By minimizing the output to the drive transistors 
for the LCD clocks and dots, we were able to obtain regula- 
tory agency qualification. Adding a video interface loads 
these signals more than initially intended, but all parts still 
pass their margin rating. 

Circuit Architecture 

A simplified block diagram of the the controller architec- 
ture is provided in Fig. 1. The system interface consists of 
address latches to capture a 16-bit CPU address on the fall 
of the ALE (address latch enable) signal, read, write, and 
three chip select strobes, a ready signal, and an input clock 
running at 5 MHz. 

The positioning of the LCD controller directly on the 
CPU bus eliminates the need for additional buffers in the 
system, but increases the capacitive loading on an already 
heavily taxed CMOS 8086 microprocessor. The three chip 
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( a ) Fig. 2. Photograph comparing 

LCD controller board space in The 
Portable (I) to the size ol the 25-lme 
LCD controller hybrid used in the 
Portable Plus (r). 



selects regulate three different functions of the controller. 
The selection of memory chip select (CSM) generates an 
access to display RAM and the activation of CSPPU (PPU 
chip select) generates an access to the PPU shift register. 
The PPU (peripheral processor unit) is a separate processor 
in The Portable and Portable Plus that controls the switches 
thai power the system (see article on page 4). 

By decoding the three lowest address bits and sending 
an I/O chip select (CSIO) to the chip, each of the read/write 
registers can be accessed. These registers are the A status 
register, the top-of-page register, and the cursor register. 
The status register contains bits that dictate the mode in 
which the controller operates. By setting the appropriate 
bits in this register, the programmer can control whether 
the display is blanked, alphanumeric, or graphics, and 
select the type of cursor (box or underline) and the number 
of lines locked at the bottom of the screen (0, 1, 2, or 3 
softkey rows). 

Two internal PLAs control the contents of two ALU reg- 
isters: the top character address (TCA) and bottom character 
address (BCA) registers. Upon reset the ALU fetches the 
top character address from the TCA register and, using a 



hardware subtractor, generates subsequent addresses for 
screen fetches. The BCA register is used in alphanumeric 
mode to keep track of the RAM address being pointed to 
in the lower two quadrants of the display. Constants used 
to generate the proper RAM addresses are kept in a ROM 
located within the ALU. The ALU also uses its subtractor 
to check if the address being pointed to by either the TCA 
or the BCA register matches the cursor address. If a match 
is found, the character font is automatically modified to 
display the selected cursor. 

The display RAM interface is also controlled by the PLAs. 
The mapping of display RAM onto the screen depends on 
whether the controller is in alpha or graphics mode. In 
alpha mode, characters are stored as ASCII values with 
attribute bits. Selectable attributes include underline, in- 
verse video, blinking, and a choice of three fonts which 
are software defined within the display memory. Upon 
fetching a character, the ASCII code and the font attributes 
are converted into a font address. The lower three bits of 
this font address are dictated by the current dot row. It is 
this font address whose data is the actual bit pattern sent 
to the screen. 
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Creating Plug-In ROMs for the 
Portable Plus Computer 

by William R. Frolik 



HP'S PORTABLE PLUS COMPUTER was designed 
with multiple plug-in ROM applications in mind. 
By enhancing the internal ROM disc concept used 
in its predecessor, The Portable, il has been made possible 
to custom bundle just about any application into the 
machine. This provides an expandable computer system 
that the user can easily customize by building in permanent 
software of the user's choice or design. 

Until now, there has been no easy way for either the user 
or software vendors to produce programs in ROM form. 
What we needed was a way that this could be done by (he 
customer, without requiring any assistance from Hewlett- 
Packard. 

The Portable Plus ROM IMAGE Development Package 
was written for just this purpose. Used together with an 
additional RAM module and a peripheral EPROM program- 
mer, it enables any Portable Plus to become a plug-in ROM 
development system. With the addition of a special ROM 
simulator card, the user can test the appearance and be- 
havior of the final product before creating a ROM. 

The ROM IMAGE Package consists of three parts: 

■ An installable electronic disc driver that assigns and 
maintains the RAM space in which the user creates an 
image of the final ROM 

■ A ROM image maintenance utility, with which the user 
can adjust the ROM's appearance into its desired final 
form and then save it in an MS '"-DOS file 

■ A data transfer utility for copying the saved ROM image 
file to an external EPROM programmer or other device 
for conversion into one or more ROMs. 

Electronic Disc Driver 

The key component in the ROM IMAGE Package is an 
installable electronic disc driver called EDISK.SYS. This 
driver is used to set up and control one or more virtual 
disc drives in the Portable Plus in which the user constructs 
an image of the final ROM product. These virtual drives 
exist in addition to the two built-in electronic disc drives, 
A: and B:. and any external drives that may be in the system. 
When used in conjunction with one or more optional ROM 
simulator plug-in cards. EDISK.SYS sets aside the available 
RAM on the cards (generally some multiple of 256K bytes) 
into one or more drives of usable disc space. If used without 
a simulator card, EDISK.SYS attempts to acquire enough 
system RAM (in multiples of 64K bytes, up to a maximum 
of 256K bytes) to form one or two drives of usable disc 
space. Once EDISK.SYS has been installed and the virtual 
disc space has been allocated, the user is free to use the 
space in the same way as any physical disc — it must be for- 
matted before it can be used, it has its own drive identifier 
and root directory, the user can build subdirectories and 
copy files, and so forth. 



After the user has determined what the final ROM design 
should contain, the first step in building a plug-in applica- 
tion ROM is to set up an electronic disc, drive of appropriate 
size and structure using EDISK.SYS with an appropriate 
DEVICE ■ command in a CONFIG.SYS file. Rebooting the sys- 
tem causes the driver to be installed and the virtual disc 
drive(s) to be allocated. The user then treats each drive as 
though it were any normal physical disc; application pro- 
grams and files are added using the usual MS-DOS com- 
mands. Once all of the desired files, programs, and sub- 
directories have been stored on the virtual disc drive, the 
user runs the IMAGE.COM utility. 

A user does not have to be creating a plug-in ROM to 
use EDISK.SYS. In a simple and effective way, EDISK SYS 
provides an extra bit of fast-access file storage by allowing 
the addition of another electronic disc drive in the machine. 
However, drives set up by EDISK.SYS are volatile — their 
contents vanish if the computer is rebooted. 

ROM Image Maintenance 

IMAGE.COM is a ROM image maintenance utility. Used in 
conjunction with EDISK.SYS, IMAGE.COM is used to mark 
appropriate information into the boot sector of the virtual 
disc so that it conforms to the format of all plug-in appli- 
cation ROMs. Think of IMAGE COM as sort of a ROM image 
formatter and debugger. 

When IMAGE.COM starts running, the first thing it does 
is look for EDISK.SYS among the currently installed device 
drivers. If it is not found, an error message is issued and 
IMAGE.COM terminates. If it is found, IMAGE.COM retrieves 
information from EDISK.SYS about the currently installed 
virtual drives and then prompts the user for a command. 
From this point on. the program input is interactive. The 
user has available a variety of commands that can be used 
to make the electronic disc drive appear in the desired 
final ROM form. 

In all but the most elaborate situations, the user generally 
goes through nine steps to finalize the ROM design and 
prepare it for transfer to an actual ROM or EPROM: 

1. The MARK command is issued first. This formats the 
drive's boot sector so that, in the final ROM, it will be 
recognized by the BIOS ROM driver as a plug-in appli- 
cation ROM. A "ROM existence" byte is added, along 
with a time-and-date stamp. 

2. The user specifies an 8-character name for the plug-in 
ROM using the ROMNAME command. This name becomes 
the name of the drive B: subdirectory in which the ROM's 
contents will appear. For example, if the ROM name is 
HPTOOLS. the entire contents of the virtual drive will, 
in ROM form, be mapped into the subdirectory 
B:HPTOOLS. 

3. The OEMNAME command is optionally issued. This is 
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Structure of a Plug-In ROM 
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4 ROM Files, which includes: 

• Subdirectory files (if any, must come first) 

• Programs, data, batch files 

• ROM-executable code 

FF (Last sector of a half-bank ROM) 
1FF (Last sector of a full-bank ROM) 



The Portable Plus supports two variations of plug-in ROM the 
hall bank ana the full bank While each has its own advantages 
ana disadvantages both forms share the common disc-like struc- 
ture shown in Fig 1 Each plug-in ROM is structured lo look like 
a coitiplete disc The system's memory management code com- 
bines the file allocation tables ana root directones of the individual 
ROMs "on the fly" into a single file allocation table and too! 
directory lor drive B: (see article on page 21 ) 

The boot sector is nol really a boot sector since the system 
does not attempt to boot from it However, it does contain BIOS 
parameter block information like a normal disc's boot sector In 
addition, it contains a ROM name, an optional OEM name, a 
time-and-date stamp, and a ROM type identifier and checksum 
information 

The ROM chips that compose a full-bank ROM come in pairs — 
one set of chips (or more, if EPROMs are used) covers the odd 
addresses, and an equal number of chips covers Ihe even ad- 
dresses The EDISK.SYS driver partitions a single contiguous 
block of memory into a full-bank structure. Even and odd RAM 
addresses correspond to even and odd bytes within sectors. 
The entire drive maps one-lor-one with Ihe allocaied RAM When 
image.COM saves the drive image, il makes two passes through 
ihe data. The first pass copies all of Ihe even-addressed bytes 
into a file ending with .EVN and the second pass copies ihe 
skipped odd-addressed bytes inio a file ending with .odd When 
the pair ol ROMs are installed in the system, the BIOS verifies 
that they are a correctly installed full-bank pair by examining the 
first word of the boot sector The byte at bool sector address 0 
(the first byte of the .evn half) must contain B2 n6 and the byte 
al bool sector address 1 (the first byte of Ihe ODD half) must 
contain B1 16 . If these ROM "existence" bytes are incorrecl. Ihe 
BIOS reiecls the ROMs and ignores them. 

A half-bank ROM can be a single chip — Ihe entire drive struc- 
ture is linearly stored within one or more chips with no differen- 
tiation belween even and odd-addressed bytes Address 0 within 
Ihe ROM chip contains bool sector address 0, address 1 contains 
boot sector address 1 , and so on When plugged into a ROM 
slot, Ihe contents ol Ihe half-bank ROM will appear al every other 
address, be it even or odd, since Ihe hardware maps each whole 
ROM inlo only even or odd addresses The BIOS detects ihe 
presence of a half-bank ROM by reading the first byte ol its bool 
sector A B3, 6 byte identifies the ROM as a half bank. In access- 
ing ihe data in a half-bank ROM, Ihe ROM disc driver performs 
Ihe address mapping necessary lo read only the even or odd-ad- 
dressed bytes containing the ROM's dala Note lhat Ihis scheme 
permits Iwo hall-bank ROMs to reside adjacent to each other m 
odd and even ROM slols. If looked al on an absolute, sequential 
address basis, their contents will be interleaved Funclionally. 
however, Ihe half-bank ROM is 99% the equivalent of a full-bank 
ROM The only constraints are thai, because of its every-olher-ad- 
dress organizalion in Ihe system plug-m memory space, the half- 
bank ROM cannol contain code executable directly from Ihe 
ROM, and its maximum size is hall thai ol a lull-bank ROM 



Fig. 1. Disc-like structure of Portable Plus plug-in ROMs. 



another 8-character name that is simply written inlo the 
boot sector. It is not required by the operating system. 
4. The DIR command is optionally issued. This is similar 
to the MS-DOS DIR command, except that it shows only 
the contents of the drive's root directory. An importanl 
feature is that, unlike the MS-DOS version, the DIR com- 
mand also shows deleted files, the initial sector (and 



paragraph) address of each file, and whether or not each 
file occupies contiguous sectors. (A ROM-executable file 
is created by storing a program file in the root directory 
of the virtual drive, ensuring thai it occupies contiguous 
sectors, and Doling its initial paragraph address. A small 
separate front-end program is then added to enable the 
ROM and jump to that initial paragraph.) 
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5. The FENCE command is issued. One of (he requisites of 
a plug-in ROM is that all subdirectory files reside ahead 
of program and data files; the last subdirectory (or root 
directory) sector is the "fence" between the directory 
structure and all other data. The FENCE command scans 
the directory structure of the drive in an attempt to 
locate the fence. If found, its position is written into the 
boot sector. If any nondirectory files appear ahead of 
subdirectory files, the corrupt structure is reported to 
the user. 

6. The CHECKSUM command is issued. This checksums the 
entire contents of the drive, writing the result into the 
boot sector. It is important that this be done last, since 
most of the preceding commands alter data in the drive's 
boot sector, which in turn affects the checksum. 

7. The STATUS command is optionally issued. This dis- 
plays a synopsis of the drive's boot sector. 

8. If all is well, the SAVE command is issued. This com- 
mand stores the entire image of the virtual drive into 
one or two MS-DOS files on some other (probably exter- 
nal) drive. If a half ROM bank is being constructed, one 
file with the extension HAF is written. If a full ROM 
bank is being constructed, two files, with the extensions 
EVN and ODD, are written. 

9. The QUIT command is issued, causing IMAGE.COM to ter- 
minate. 

IMAGE.COM provides several additional commands 
which, while generally not required, can be used to 
examine or alter the structure of the ROM. An ENTER com- 
mand, for example, permits individual bytes to be entered 



into any address in the disc structure. The HIDE command 
can be used to hide a root directory file so that it will not 
show up in a normal MS-DOS directory listing. INITCODE 
can be used to copy a small executable file into the normally 
unused leftover space in the boot sector. Each time the 
system is reset, this code can be downloaded into system 
RAM and executed. Typing HELP, or just ?. causes ROM 
IMAGE to display a list of all supported commands. 

At this point, the final ROM image is totally contained 
in one or two normal MS-DOS files, ready to be transferred 
to ROM or EPROM. Included in the package is a data trans- 
fer program. BURN.COM, which can be used to copy each 
image file to an EPROM programmer (or any other device) 
via one of the supported transfer formats (Intel MDS 
hexadecimal. Motorola Exorcisor hexadecimal, RCA COS- 
MAC hexadecimal, unformatted ASCII hexadecimal, or raw 
binary). 
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Andy Davidson has been 
an HP R&D engineer since 
1980 He has contributed to 
ihe development ot the 
HP-86andHP-87 Personal 
Computers, the modem tor 
The Portable, and Ihe 
power supply lor the Port- 
able Plus He was also a 
production engineer lor the 
HP-87 and was coauthor ol an HP Journal article 
on Series 80 HP Computers Born m Abmglon, 
Pennsylvania, he earned a BS degree m electrical 
and computer engineering Irom Clarkson College 
ol Technology in 1980 He s a resident of Corvallis. 
Oregon, is married, and has one daughter Heen- 
|oys listening to music and playing his guitar 




18 — Personal Applications Manager : 



Alesia Buncombe 

A software engineer with 

ijf^^^k Division, Alesia Duncombe 

Jk has been with the company 

9f - '^U since 1979 Her first |0b at 

| W HP was .n technical cus- 

^9 m lomer support, and alter 
^^^^^ rnpleting her studies lor 

^^HH^H gon State University m 
1981. she moved to an R&D position She has 
worked on the design and implementation ol 
operating system firmware tor Ihe HP ThmkJet 
Printer and for the Portable Plus Alesia was born 
m Seattle. Washington and is currently living in El 
Cerrito. California while her husband, also an HP 
engineer attends graduate school They are the 
parents of a baby boy Her hobbies include skiing, 
sewing, backpacking, and travel. 



Robert B. May 




Bob May was born m Belle- 
ville. Illinois and grew up in 
Albuquerque. New Mexico 
He began working for HP 
as a part-time student in 
1 980 and earned a BS de- 
gree m computer science 
m 1981 from the New 
Mexico institute of Mining 
and Technology His con- 



tributions as an R&D engineer include working on 
several ROMs for the HP-86 and HP-87 Personal 
Computers and developing system software for the 
internal modem and serial port for the Portable 
Plus He also developed an arcade game for the 
HP-86 and HP-87. which HP has sold through the 
employee software program Bob and his wife live 
m Corvallis, Oregon He likes touring Oregon 
wineries, riding his mountain bike, and cooking 
Mexican food 
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Mark S. Rowe 

An alumnus ol the Univer- 
sity ol California at Davis. 
Mark Rowe holds a 1973 
BS degree m computer sci- 
ence and a 1 977 MSEE de- 
gree With HP since 1975 
he nas contributed to the 
development of the HP 
7910 Disc Drive and the 
HP- 75 Handheld Comput- 
er He worked on application software and testing 
for The Portable and wrote the memory manage- 
ment software for the Portable Plus Mark was born 
m Sacramento, California and now lives in 
Philomath. Oregon He s married and has a son 
and a daughter He likes to spend his free time sail- 
ing his family's 26-foot sailboat and also has a pri- 
vate pilot's license with glider and instrument 
ratings 
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Glenn J. Adler 

Born in Englewood, New Jersey, Glenn Adler 
studied electrical and biomedical engineering at 
Brown University and completed work for his BS 
degree m 1981 He came to HP the same year and 
was an IC designer and a production engineer lor 
The Portable and HP Series 80 Personal Comput- 
ers before leaving HP He s the author ol an article 
on liquid-crystal displays and is interested in 
neurosciences and electrical modeling He likes 
ultimate fnsbee, skiing, and \azz. 
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William R. Frolik 

An Oregon native. Bill Frolik 
has been with HP's Port- 
able Computer Division 
since 1 980 He designed 
the extended memory con- 
troller for Ihe HP-86 and 
HP-87 Personal Computers 
and was an IC production 
engineer for both products 
i He was also a designer ot 
the CMOS ROM lot The Portable and was a 
member of the system firmware team for the Port- 
able Plus Bill was bom m Corvallis and earned a 
BS degree in physics from Willamette University m 
1979 He completed work for his MSEE degree 




from Stanford University m 1 980. He currently lives 
m Corvallis and has many oulside interests, includ- 
ing photography, piano, woodworking, skiing, ten- 
nis, bicycling, golf, landscaping, and travel 
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Robert J. Schneider 

Born in Syracuse. New 
York, Bob Schneider has 
been an HP software en- 
gineer since 1983 He 
worked on the HP-UX de- 
vice I/O library definition 
v h and on its implementation 
_* "^^r lor me HP-UX system for 

W/f . the HP 9000 Series 500 

Computer He studied 
computer science at the University ol Vermont 
(BSCS 1981) and al Oklahoma State University 
(MSCS 1983) His protessional interests include 
operating systems and non von Neumann com- 
puter architectures Bob and his wife live in Fort 
Collins, Colorado. During his leisure time he enjoys 
sailing, skiing, guitar, and piano 



David L. Frydendall 

— || r David Frydendall studied 
I -^flW^HK corn P u,e ' science at Coi- 
„JJ*^ '^^Hft:'9 orado State University (BS 



ib^^k 1976) and at the University 

'fi^^L^L 01 Coloraa ° ' MS 1982 > 
■M Y Alter working on several 

PQ^MM^MM computer graphics pro|- 

-af^^^^^^^^^H ects tor Sperry Univac. 

vj^HnS^^ lOinedHPin 1978 His first 
i^^^HIHH^fci. assignment was on the HP 
1350S Computer Graphics System. Later he de- 
veloped the 1 6-bit parallel and serial drivers for the 
HP 9000 Series 500 Computers. He also contrib- 
uted to the HP NS/9000 LAN (or the Series 500 and 
initialed Ihe development of windowing software for 
HP 9000 Computers A Colorado native, David was 
born in Greeley. He's married, has a son, and lives 
in Fort Collins When not working on the construc- 
tion of his mountain home, he enjoys music, camp- 
ing, fishing, and cross-country skiing 



Robert M. Lenk 

Bob Lenk was born in New 
York City and is an alumnus 
of the University of Connec- 
ticut He completed work 
for his BA degree in mathe- 
matics in 1975 and for his 
MS degree m computer sci- 
ence in 1 98 1 . With HP since 
1981, he's a software de- 
velopment engineer and 
has worked on the HP-UX system kernel for HP 
9000 Series 500, 200, and 300 Computers. His 
other major contribution has oeen on the HP NS/ 
9000 LAN lor the Series 500 Computer He is a 
coauthor of several technical papers and is in- 
terested in operating systems. Bob and his wife 
are residents of Fort Collins. Colorado His out- 
side interests include cross-country skiing and 
gardening. 
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Bonnie Dykes Stahlin 

|^^F C - H manager .•. 

5] - at 

. / y was bom .n Wtay. Color aoc 

S^Fi ' and stuOieo compiler SC'- 

ence at Colorado Stale University Sne received 
her BSCS degree n 1978 and her MSGS degree 
m '983 She and her husband are residents of 
Loveland. Colorado and her outside interests in- 
clude sailing, windsurfing, camping, and sewing 
She's also a fitness instructor for the health and fit- 
ness program at her division 



Andrew 



Andrew G. Anderson 

Drew Anderson was bom m 
Rochester Minnesota and 
educated at the University 
of Minnesota at Minneapo- 
lis-Sl Paul He received a 
BS degree <n mathematics 
m 1 982 and a BS degree in 
amputer science m 1984 
kr, *M He has been with HP since 

fe- 1 .m '984 and has worked on 

the HP-UX system kernel for the HP 9000 Series 
200 and 300 Computers. He was a musician lor ten 
years belore coming lo HP Drew and his wife and 
Iwo children live in Fori Collins, Colorado During 
his leisure lime he coaches his son's soccer learn 



Robert D. Gardner 

Wilh HP since 1983 Rob 
Gardner is a specialist in 
APl data communications and 
f9 ^\ UNIX systems He has 

I SL- M worked on asynchronous 
•Cn^ data communications and 
g^KJ on lermmal emulalors lor 

4 if the HP-UX syslem and has 
\ wrilten dala commuruca- 
» i lions software lor HP 150 

Personal Computers and for the X 25 networking 
protocol He's ihe author of a paper on dala com- 
munications and coaulhor ol a paper on graph 
theory Bom m New York City, Rob has a BS degree 
in computer science and an MS degree In 
malhemalics Irom Oarkson Univers>ly Both de- 
grees were awarded in 1 983. A resident of Fori Col- 
lins Colorado, he en|oys chess, music, lennis. 
mathematical puzzles, and molor spons He also 
reads science fichon and brews beer 



Ronald G. Tolley 



Born m Sail Lake City. Utah. 
Ron Tolley graduated from 
Ihe University of Utah In 
1976 with a BSEE degree 
and Irom Purdue University 
In 1981 wilh an MSEE de- 
gree He came lo HP in 
1978 and has developed 
sotlware lor the HP 9845B 
Computer and Ihe HP 9000 



Senes 500 Computer His work on the HP-UX sys- 
tem nas been m the areas of system performance 
and native language support His professional in- 
terests include data 'low computation inter- 
nationalization, computer grapnics and image 
processing Ron lives in Lovetand Colorado s 
named, and has 'ive children He's active ft bis 
church and in local political activities and likes ter - 
ms vocal music and creating water color and pas 
lei pictures 
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James M. Umphrey 

A project manager at HP's 
Colorado Telecommuni- 
cations Division, Jim 
Umphrey has contributed 
lo Ihe development of a 
number ot oscilloscopes, 
pulse generators, and pro- 
tocol analyzers since |oin- 
mg HP in 1961 He was 
project manager lor Ihe HP 
497 1 S Protocol Analyzer Born in Eugene Oregon. 
heallendedSianlord University, receiving a BSEE 
degree m 1961 and an MSEE degree in 1964 His 
work on sampling is Ihe subiecl ot a palenl and he 
is ihe author ot several technical papers Jim Is 
married and has five daughters, including a set of 
twins He lives in Colorado Springs, Colorado is 
active in Big Brolhers. and likes woodworking, run- 
ning, and reading 



Jeffrey Tomberlln 

Jeff Tomberlin was respon- 
sible for Pascal and assem- 
bly language programming 
lor the HP 497 IS Prolocol 

f— _ Analyzer and aiso contrib- 
uted to the analog and dig- 
ital design and assembly 
language software lor the 
HP 4945A Transmission 
Impairment Measuring Sel 
Born in Evansion, Illinois, he completed work for his 
BSEE from Georgia Institute of Technology m 1 980 
and came lo HP Ihe same year His professional 
specialties are real-time soltware and hardware in- 
terfaces He lives m Colorado Springs. Colorado 
and enpys swimming, bicycling, hiking, and skiing 
during his leisure hours. 




Jeff Smilh is a Stanlord Uni- 
versity alumnus wilh a 1 962 
BSEE degree and a 1963 
MSEE degree He has been 
wilh HP since 1 963 and has 
contributed lo ihe design ol 
a number ol sampling oscil- 
loscopes, pulse generators, 
and logic analyzers He's 
named inventor on a palenl 
related to sampling oscilloscopes and is Ihe author 
or coaulhor ol several HP Journal articles and con- 




andinel 



ierence papers Sc-m m Portland. Oregon fie « a 
resident of Colorado Springs. Colorado, is married 
and nas tnree CH fc fr W He ■& restonng a viniage 
Corvette and enioysruming. sailing, woodworking, 
and working with stained glass 



Gordon A Jensen 

Gordon Jensen is a 
graduate ol the Unrversity 
of California at Davis He 
completed work lor his 
BSEE degree vn 1981 and 
came to HP the same year 
He s a hardware designer 
and has worked on the HP 
I 4945A Transmission Im- 
EJ pairmen! Measuring Set 
le is named coinvenlor for two 
palenl applications on LAN protocol analysis and 
is coauthor ol a 1 984 HP Journal article on the HP 
4945A Born in Santa Ana. California, Gordon lives 
in Colorado Springs. Colorado His outside in- 
terests include skiing, mountain climbing, bicy- 
cling, and exploring the American Southwest. 



Stephen P. Reames 

With HP since 1979. Sieve 
Reames is an R&D en- 
gineer at Ihe Colorado 
Telecommunications Divi- 
sion. He has worked on Ihe 
HP 3326A Synthesizer. Ihe 
HP 4937A Transmission 
Impairment Measuring Sel. 
and the HP 4971 S. His work 
on Ihe HP4971S involved 
me hardware design of Ihe interlace lo Ihe LAN He 
was born in Boston. Massachusetts and graduated 
Irom ihe University of California at Berkeley wilh a 
BSEE degree in 1979 He is named coinvenlor lor 
iwo palenl applications on LAN prolocol analysis 
and he's Ihe aulhor ol a tutorial article on lelephone 
signaling Steve lives in Colorado Springs and 
spends his spare lime exploring Colorado, 
spelunking, and flying radio-controlled sailplanes 



Jerry D. Morris 

Jerry Morris has been wilh 
HP since 1975, Ihe same 
year he received a BSEE 
degree from Iowa Siale 
University After an assign- 
ment in produclion en- 
gineering he moved lo an 
R&D posilion and has done 
analog, digital firmware, 
'i/ and software design for the 
HP 4960A and HP 4961 A Pair Identifiers, the HP 
4945A Transmission Impairment Measuring Sel, 
and ihe HP 497 1 S Prolocol Analyzer A patent ap- 
plication has resulted Irom his work on a runt filter 
lor Ihe HP 4971 S He holds an MSCS degree from 
Ihe University ol Sanla Clara ( 1 983) and was a com- 
puter repair instructor while he served in Ihe U.S 
Army Born In Des Moines, Iowa, he s married and 
lives in Colorado Springs, Colorado He enioys 
music and photography when no! working on home 
remodeling pro|ecls 
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New HP-UX Features for HP 9000 Series 
300 Workstations 

The capabilities of the HP-UX operating system have been 
extended in the Series 300 implementation to handle real- 
time applications, communication with X.25 networks, and 
operation in native languages. 

by Andrew G. Anderson, David L. Frydendall, Robert D. Gardner, Robert M. Lenk, Robert J. Schneider, 
Bonnie Dykes Stahlin, and Ronald G. Tolley 



SINCE ITS INTRODUCTION on HP 9000 Series 500 
Computers in 1983, w,a the HP-UX operating system 
has been implemented on HP 9000 Series 200 Com- 
puters and the Integral Personal Computer. 4 In that time it 
has grown from a superset of AT&T Bell Laboratories' 
UNIX'" System III'" to a superset of AT&T's UNIX System 
V™, release 2. In addition, the HP-UX operating system 
has been extended in several directions that are important 
to Hewlett-Packard's traditional technical computer cus- 
tomers. All such extensions have been defined very care- 
fully to fit in with the industry standard UNIX System V 
definition while providing added needed functionality. 

The HP-UX 5.0 release is the first version for the Series 
300. and the 5.1 release is a common version for both the 
Series 200 and Series 300. These releases provide many of 
the features previously available only on the Series 500. 
such as virtual memory and local area networking. 5 In ad- 
dition, they introduce a number of important new features 
not found on the earlier HP-UX system. These features 
include support for device I/O, extensions for real-time 
programming, support for communications over an X.25 
network, support for users' native languages, and a win- 
dow-oriented human interface for the new bit-mapped dis- 
plays developed for the Series 300. Most of these new fea- 
tures are also provided for the Series 500 in its HP-UX 5.0 
release, and on the new HP 9000 Series 800. Many are 
available on the Integral PC as well. 

Device I/O 

Standard implementations of the UNIX operating system, 
while addressing the needs of software developers, do not 
provide the device I/O capabilities required for instrument 
controller systems. However, to be useful in solving scien- 
tific and technical problems, such instrument controller 
capabilities must be present. 

To ensure a successful design and implementation that 
would solve instrument controller problems, we had to: 

■ Provide the functionality for full control of the HP-IB 
1 (IEEE 488/TEC 625) and the 16-bit parallel GPIO (general- 
purpose input/output] interface cards. 

■ Define an HP-UX standard for the device I/O functional- 
ity to ensure portability of solutions across the entire 
HP-UX-based product family. 



■ Maintain a unified I/O approach by using the existing 

I/O functionality provided in the HP-UX system. 

Achieving the second objective required that differences 
in hardware and operating systems be hidden. This was 
accomplished by implementing the user interface al the 
library level. The device I/O library combines with the 
HP-UX system to provide a total I/O solution (Fig. 1). The 
library provides functions for controlling devices while the 
system provides functions for reading and writing data. 

The device I/O library defines three classes of functions. 
The first class includes generic functions that apply to both 
interface cards. The second class of functions applies to 
the HP-IB interface card only. The third class of functions 
applies to the GPIO interface card only. The GPIO functions 
allow for setting control lines and reading status lines. The 
HP-IB functions allow for obtaining bus status information, 
conducting serial or parallel polls, addressing the bus. and 
performing several controller-related actions. The generic 
functions include such capabilities as setting time-outs and 
data path widths. In addition, the HP 9000 Series 300 HP- 
UX implementation provides an additional function within 
its I/O library for enabling a high-speed HP-IB instrument 
data transfer mode. 

The ability to transfer small data packets at high speed 
is critical in many instrument controller applications. To 
provide this capability, a new function called ioburst was 
added to the I/O library. This function allows the calling 
process to enable or disable burst mode. Normally, a data 
transfer request results in a system call to the kernel to 
perform the actual I/O. When burst mode is enabled, the 
memory mapped I/O address space of the interface card is 
mapped directly into the user's address space. This allows 
the user to talk directly to the interface card without the 
overhead of a kernel call. Burst mode significantly im- 
proves the performance for reading and writing and send- 
ing HP-IB bus configuration commands. All other opera- 
tions are unaffected and take their normal path through 
the HP-UX kernel. 

After the interface card is mapped into the user's address 
space, subsequent data transfer requests are intercepted by 
the I/O library and directed to special data transfer routines 
in the library. These routines directly access the interface 
card through the user's address space. The typical path has 
been tuned to less than 50 processor states and results in 
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Fig. 1 . Sophisticated instrumentation solutions are possible 
with a Series 300 Computer interfaced to the instruments 
using the HP-UX 5.0 device 110 library 



reducing the operating system overhead for a given data 
transfer by approximately two orders of magnitude for the 
Model 320 Computer. 

Burst mode provides the fastest path for the transfer of 
small data packets typical of instrumentation systems. Very- 
large data packets can be transferred faster by the HP-UX 
kernel using DMA. In systems where DMA is not available, 
burst mode always provides the fastest path. The break- 
even point is approximately 4K-byte packets on a Model 
320 system. Larger packets can be transferred faster by 
DMA and smaller packets are transferred faster using burst 
mode. For example, reading an 8-byte packet from a volt- 
meter using a Model 320 will take approximately 114 fis 
in burst mode and approximately 7422 jxs using DMA. 

The Nelson benchmark 6 is commonly used to measure 
the performance of instrument controller systems. Running 
this benchmark on a Model 320 produced a result of 385 
readings per second, which approaches the theoretical 
limits of the HP 3495A Scanner used. This is almost two 
times faster than the BASIC operating system running on 
a Model 320 Computer, which attained a rate of 230 read- 
ings per second. 

Real-Time Extensions 

Having been developed for timesharing applications, 
most UNIX systems do not provide the features or perfor- 
mance necessary for real-time applications. Some of the 
features included in the HP-UX system as part of its UNIX 
System V implementation are designed to meet some of 
the needs for real-time applications. In other cases, features 
have been taken from one of the other popular UNIX ver- 
sions iti the marketplace, 4.2BSD, which was developed at 
the University of California at Berkeley. When no appro- 
priate feature existed in the marketplace, a new one was 
defined to fill the void. A more detailed description of 
these extensions appears in reference 7. 

The definition used here of a real-time application is one 
that must reliably interact with or respond to entities out- 
side the computer on a time schedule that is driven by 



those outside entities. This definition is extremely general, 
since it can be applied to virtually any computer applica- 
tion. The key is that real-time does not define a black-or- 
white distinction that can be applied to applications or to 
operating systems: it defines a continuum of requirements. 
Near one end of the continuum are applications that need 
to respond to discrete inputs such as keystrokes. The gen- 
erally accepted response time for such applications is about 
one tenth of a second. Standard UNDC systems are generally 
designed to perform well in this area, but not much beyond 
it. Those applications at the other end of the continuum 
will most likely need custom operating systems to get the 
most out of any given hardware and meet their goals. How- 
ever, there are many applications that fit somewhere in the 
middle, including those that run on HP's BASIC and Pascal 
Workstations and HP 1000 Computers. The purpose of the 
real-time extensions is to allow the HP-UX system to cover 
a larger segment of this continuum. This gives application 
writers and users the advantages of an industry standard 
operating system, and still allows them to solve their prob- 
lems. 

One of the key limitations in the standard UNIX feature 
set is in the resolution of primitives that deal with time. 
The standard primitives for scheduling events at a given 
time have a resolution of one second, which is insufficient 
even when dealing with humans. A feature known as inter- 
val timers was taken from the 4.2BSD system to address 
this problem. Each process can schedule either a single 
interrupt or regularly repeating interrupts with whatever 
precision the underlying hardware and operating system 
support. The interval is expressed in units of seconds and 
microseconds to keep the interface portable despite the 
system-dependent resolution. The supported timer resolu- 
tion on the Series 300 is 20 milliseconds. 

Another limitation is the minimal set of interprocess 
communication mechanisms available. There are only two 
mechanisms common to all UNIX systems, pipes and sig- 
nals. These facilities have various weaknesses in function- 
ality, performance, and reliability. The latest release of the 
HP-UX system includes three new interprocess communi- 
cation facilities from UNIX System V. plus a reliable signal 
interface based on one introduced in the 4.2BSD system. 

The three facilities from UNIX System V are semaphores, 
messages, and shared memory. The semaphore mechanism 
is very elaborate, allowing solutions to both simple and 
complex synchronization problems. The message passing 
mechanism allows transfer of data without any disc access, 
and provides features such as tagging and prioritization of 
messages that are unavailable with pipes. The shared mem- 
ory facility is probably the most important for real-time 
needs, allowing by far the highest communication band- 
width, since data does not need to be copied to be com- 
municated. In the Series 300 Computers, shared memory 
is paged by default, but can be locked in main memory to 
provide optimal performance. All three of these mecha- 
nisms share an interface that allows communication and 
synchronization among arbitrary unrelated processes, yet 
provides protection from unauthorized access. 

Signals are essentially a software interrupt mechanism, 
but the standard UNIX definition includes several race con- 
ditions which make the mechanism unreliable for inter- 
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process communication. The 4.2BSD system introduced a 
new signal mechanism to solve these reliability problems. 
Modeled after hardware interrupts, its main contribution 
is the ability to mask out signals to eliminate race condi- 
tions. The major shortcoming of this new definition is that 
it does not allow lull emulation of the standard signals 
used in virtually every other UNIX system, including early 
HP-UX systems. This is because of an orthogonal change 
that transparently restarts system calls that have been inter- 
rupted by signals. A few minor modifications to this portion 
of the 4.2BSD definition yielded one for the HP-UX system 
that can completely emulate both the standard UNIX mech- 
anism and the new 4.2BSD mechanism. The HP-UX defini- 
tion allows the user to choose whether an interrupted call 
is restarted as in 4.2BSD or aborted as in the standard UNIX 
mechanism. 

Another limitation in standard UNIX systems is the de- 
gree of control available over process priorities. The UNIX 
process priority structure was designed for multiuser 
timesharing systems, with major goals of fairness to all 
users and acceptable response to users at terminals. To 
achieve these goals, the system dynamically adjusts process 
priorities, favoring interactive processes with light CPU 
use at the expense of those using the CPU heavily. Users 
are given some control of priorities with the nice system 
call, but the values specified by it are actually only one 
factor in a formula. As a result, it is difficult or impossible 
to guarantee that one process has an effective priority 
greater than another. In addition, processes executing 
within the kernel often have their priorities increased to 
favor them over any process executing user code. The 
priorities used in these situations are based only on the 
kernel code being executed, not the original priority of the 
process. Thus low-priority processes inside the kernel are 
favored over high-priority ones outside the kernel or in 
different portions of the kernel. 

Since these problems have not been addressed in any of 
the commonly available UNIX systems, a new solution is 
introduced with the real-time extensions of the HP-UX sys- 
tem. This solution extends the priority model with a new 
range of priorities, named real-time priorities, and a new 
system call rtpno. which allows processes to set their 
priorities in this range. Priorities in the real-time range are 
not dynamically adjusted by the operating system, but 
maintain absolute values as set by the user. Any process 
with a priority in this range is favored over any user process 
with a priority in the normal range, regardless of whether 
either process is executing kernel or user code. Further- 
more, the rtpno call allows processes to read and modify 
not only their own priorities, but also those of other pro- 
cesses owned by the same user. Processes with priorities 
in the normal range continue to behave with the standard 
UNIX semantics. 

One major factor in the real-time response of some appli- 
cations is the speed at which they can log data to disc files 
or read the data logged by other processes. The mechanism 
used by the standard UNIX file system to allocate file space 
does not lend itself to optimal performance in this area. 
File space is allocated only at the time a write is performed, 
adding new blocks to the file as needed from a list of free 
blocks. In the case of a single application writing to a freshly 



formatted file system, this may produce an optimal file 
layout. However, as files are created and destroyed, the 
free block list tends to become random, as does the layout 
of any given file. 

The 4.2BSD file system implementation is better suited 
for optimal file layout than the standard UNIX implemen- 
tation. It partitions disc space into cylinder groups with 
small seek times within any one group, and attempts to 
allocate space for a given file from a single cylinder group. 
Unrelated files are placed in different cylinder groups to 
minimize contention for the same space. A bit map of free 
blocks in each cylinder group is maintained and used in 
place of the linear free block list. The Series 300 HP-UX 
system uses essentially the 4.2BSD implementation, with 
minor modifications to eliminate incompatibilities with 
other UNIX and HP-UX systems that are visible to the user. 
Even though this implementation almost always results in 
more optimal file layouts than the free block list algorithm, 
the layouts can be unnecessarily fragmented when file 
space is only allocated as data is written. Thus a new system 
call prealloc is included in the real-time HP-UX extensions. 
As the name suggests, this call is used to preallocate space 
for a file before the actual data is written. 

The Series 300 virtual memory system supports user pro- 
cesses whose individual or combined sizes exceed physical 
memory. The time required to bring a page or an entire 
process from disc into memory can range from several mil- 
liseconds to several seconds, and thus can violate almost 
any real-time requirement. The effect is often a wide vari- 
ation in the performance of a given task, where the normal 
time is acceptable, but an occasional swap causes problems. 
The HP-UX system has adopted a solution to this problem 
from UNIX System V. The piock system call allows the caller 
to lock the caller's executable code and/or data in memory 
to avoid unexpected swapping and paging. In addition, as 
alluded to above, shared memory segments can be locked 
in memory with the shmctl call. 

Some of these real-time features, notably real-time 
priorities and locking of memory, allow users to degrade 
the performance seen by others on a multiuser system sig- 
nificantly. The standard approach to capabilities of this 
nature in UNIX systems is to restrict the capabilities to the 
superuser or system administrator, who by definition has 
the ability to impact all other users. Unfortunately, the 
superuser has many very dangerous powers, such as the 
ability to write or remove any file in the system, and care 
must be taken by anyone running as the superuser to avoid 
their accidental misuse. Therefore, it is not practical to 
require users using these real-time features to run as a 
superuser. 

The HP-UX system includes a new concept called 
privileged groups as a solution to this problem. Several 
potentially dangerous capabilities or privileges are ordinar- 
ily reserved for the superuser. However, the superuser can 
assign any of these privileges to a group of users, designat- 
ing that group as a privileged group. All processes in a 
privileged group are empowered with the restricted func- 
tionality. The Series 300 HP-UX implementation permits 
assignment of the real-time priority and memory locking 
privileges, as well as a third privilege not related to the 
real-time extensions. 
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One experiment has been designed and run to give an 
indication of the effect of the new features on interrupt 
response time. The measurements involved the response 
to an SRQ interrupt on an HP-IB network. The experimental 
steps performed were: 

■ A program on the host is written with the device I'O 
library- to wail for SRQ and then drop the REN line on 
the bus. 

■ A separate machine asserts SRQ. 

■ An HP 1630G Logic Analyzer clocks the interval from 
SRQ being raised to REN being dropped. 

Three conditions are varied on the host: 

1. Whether or not the system has a background load run- 
ning. The background load used consists of a C compile 
and a copy of the BID Whetstone benchmark. When the 
load is not present, the system is dedicated to the device 
I D library program. 

2. Whether or not the device I/O library program runs with 
a real-time priority (obtained with the rtprio call). Otherwise 
it uses the default nice value, as does the background load. 

3. Whether or not the device I/O library program locks 
itself in memory with the plock call. 

The results are shown in Fig. 2. The same experiment 
was run on an HP 9000 Model 550 system, and those results 
are included too. These results apply only to this experi- 
ment, and should not be extrapolated to other applications. 
In particular, the maximum times quoted are only the max- 
ima observed in these samples, and should not by any 
means be interpreted as guaranteed worst-case times for 
this or any other application. No values are given for the 
Series 300 machines on a dedicated system using rtprio and/ 
or plock. These features did not show a significant impact 
on a dedicated system, so full sets of measurements were 
not done. 

These real-time extensions have been used in developing 
the interactive Starbase Graphics Library and the HP Win- 
dows/9000 system. The results of these efforts subjectively 
show a marked improvement over previous HP-UX systems 
in smoothly tracking input devices under human control. 
These particular applications will prove very important in 
the ability of the HP-UX system to support computer-aided 
engineering. 

X.25 Extensions 

HP-UX systems have always included the standard uucp 
(UNIX-to-UNIX copy) facility lor asynchronous communi- 
cation over RS-232-C/V.24 and modem lines as described 
in reference 8. This facility has been extended to support 
connection of HP-UX systems to an X.25 network. The use 



of the X.25 Public Data Network (PDN) has become wide- 
spread in Europe and is now becoming quite popular in 
the U.S.A. as well. Although it is quite difficult (from a 
hardware perspective) and expensive to attach a computer 
to an X.25 network directly, there is a much simpler and 
cheaper solution that is effective for many applications. 
The Packet-Assembler-Disassembler (PAD) is a microcom- 
puter that has been programmed to make it easy to connect 
an arbitrary computer or terminal to an X.25 network. The 
PAD provides a standard serial RS-232-C/V.24 interface to 
a terminal or computer, does the work of electrical connec- 
tion to the network, and also handles the necessary pro- 
tocols to move data through the network. 

The HP 2334A PAD is used in the HP-UX implementa- 
tion, and is treated very much like a modem would be. 
The usual dialit mechanism is used as an interface between 
user processes and the HP 2334 A. dialit takes an X.25 address 
(analogous to a phone number for a modem), initiates the 
communication with the HP 2334A. and returns with an 
open communication line for the calling process to use. 

Several modifications were needed to accommodate 
some of the eccentricities of the PAD and the X.25 network. 
For security reasons, the PAD provides the address of the 
caller when a switched virtual circuit (SVC) is established. 
This address must be logged on the receiving system. The 
HP-UX utility getty, which usually receives incoming calls, 
does not have the capability to log the caller's address, nor 
does it have the ability to perform some simple configura- 
tion on the associated device. For these reasons, getty is 
replaced by getx25. which is almost the same, except for 
the additional features required by the X.25 network. To 
make it easy for a user to use a different PAD from the HP 
2334A. we provide facilities to make this step straightfor- 
ward. The central tool is a PAD configuration language 
which has such simple statements as send xxx and expect 
yyy. This saves the user the trouble of writing and debugging 
a C. module that would ordinarily be linked into dialit. 

The HP-UX X.25 connection has been running at many 
HP sites since mid-1984, and at several sites outside HP 
since mid-1985 when this software received official sanc- 
tion and support under HP-UX 5.0. The most common use 
is for exchange of electronic mail among distant machines. 
In terms of Iraffic amounts, notes (an electronic bulletin 
board system) accounts for a large percentage of the flow. 
Less often, the X.25 connection is used for simple move- 
ment of files from one system to another. This is particu- 
larly convenient for sending data overseas, since the phys- 
ical mailing of a tape could easily take several days, and 
most likely more. Occasionally, the X.25 link is used for a 
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remote terminal session. This setup works for many situa- 
tions, but is not supported since raw mode applications 
will not function properly unless one is willing to accept 
the inefficiency of single-character X.25 packets. 

The main accomplishment of the HP-UX X.25 connection 
has been to increase the communications capabilities of 
the HP-UX system to global proportions, and to reduce the 
cost of large-scale data traffic applications for systems sepa- 
rated by great distances. 

Native Language Support 

Native language support (NLS) provides users in the in- 
ternational market access to HP-UX capabilities that until 
now have been limited to those that speak and understand 
American English. Internationalization and localization are 
two other words that are often used to describe the same 
or similar concepts. 

Several objectives guided the development of the NLS 
product on the HP-UX system: 

■ To deliver a single product that serves the needs of all 
international users. 

■ To save disc space, especially on smaller systems, by 
separating the resources required for a specific language 
product from the executable code. The components of 
these products are tables of data used by the software in 
the base product. 

■ To allow multiple users to use the same system, each in 
his or her own native language. 

■ To permit the user to specify the desired native language 
at run time. 

■ To provide a set of tools so that software can make use 
of NLS with a minimum of added development effort. 
Three main barriers prevent an international user from 

using the HP-UX system in the user's own language: charac- 
ter set support, local customs, and messages. Bale and Kel- 
logg in their article 9 review in some detail how these limi- 
tations are being removed. 

Character Set Support. The UNIX system was originally 
used on machines that use the ASCII character set. The 
ASCII character set consists of 33 control characters (in- 
cluding DEL), the space character, and 94 printable charac- 
ters. This is sufficient to write in American English, but is 
not even sufficient for British English since the British 
pound sterling character '2 is missing. 

To provide the additional characters needed to support 
Western European and other languages, eight bits (one byte) 
are used for each character. This provides a character set 
with 67 control codes, the space character, and 188 print- 
able characters. The character set used by HP for Western 
Europe is called the Roman8 character set. 3 Other 8-bit 
character sets are also available. 

The assumption that characters are always represented 
by the ASCII character set has led to programs that cannot 
support 8-bit character definitions. For example, the vi full- 
screen editor uses the eighth bit of each byte for internal 
processing. To allow eight bits of character data, the code 
must be rewritten to store internal processing data else- 
where. Many other commands share this problem. 

A number of languages have very large character sets 
that require more than the 188 printable characters pro- 
vided by the 8-bit character codes. For example, there are 



perhaps 50,000 Japanese Kanji ideograms. While 3000 to 
7000 ideograms are required for daily use. this is well 
beyond the scope of an 8-bit character set. Sixteen-bit 
character codes are available for these languages. 

In the standard HP-UX library routines, most of the re- 
sources are hard-coded. For example, the ctype (character 
type) routines which return whether a character is upper- 
case, lowercase, numeric, et cetera access a table of 129 
bytes for the ASCII character set. As discussed earlier, this 
is not sufficient for European and phonetic Japanese 
character sets. A new family of nLctype (native language 
character type) routines has been added to the system. 
These routines access a file that contains the table for the 
RomanB character set. An integer value from the table above 
is passed to an nLctype routine to indicate which language 
to use. 

Local Customs. Some aspects of NLS relate more to local 
customs of a particular geographic location than to the 
characters used to write the language. Even the seemingly 
universal Arabic numbers are not identically formatted. 
The character used to denote the radix of a decimal number 
is a period in America, but a comma in continental Europe. 
The indicators used to separate thousands from millions 
are the reverse — a comma in America, a period in Europe. 
Thus, 1 ,432,678.09 in America is 1 .432.679,09 in Europe. 

The symbol for currency is necessarily different for each 
country. Symbols for the Japanese yen, the Dutch guilder, 
and the Italian lira are all required. The symbol may either 
precede or follow the numeric value. Some currencies 
allow decimal fractions while others use alternate methods 
of representing smaller monetary values. 

Month and weekday names vary with language (if they 
are not omitted entirely). Abbreviations may be other than 
three characters, or may not be allowed at all. Even when 
a strictly numeric representation is used, the order of year, 
month, and day and the delimiters that separate them is 
not universal. For example, the date of October 12, 1986 
is represented by 86-10-12 in Japan, by 10/12/86 or 10-12-86 
in the U.S.A.. and by 12/10/86 or 12.10.86 in Europe. 

The HP-UX system clock runs on Greenwich Mean Time 
(GMT). Corrections to local time zones consist of adding 
or subtracting whole or fractional hours from GMT. For 
example, the Cook Islands are 10 hours, 38 minutes behind 
GMT and Singapore is 7 hours, 30 minutes ahead of GMT. 
Daylight saving time (DST) in the United State and similar 
summer time zone adjustments in other countries com- 
pound the challenge of knowing the correct time. Each 
nation selects days to begin and end summer time zone 
adjustments or whether to institute them at all during a 
particular year. 

Messages. The need for messages to be readable by users 
is perhaps the most significant justification for implement- 
ing native language support. As pointed out by Bale and 
Kellogg. 9 not only do the words change from one language 
to another, but the ordering of the words within phrases 
may be different. 

The user language is selected at run time by setting the 
value of the LANG environment variable. This string value 
may take on any value shown in the second column of the 
following table: 
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While it is clearer to specify the language in a string, it 
is often easier to store and manipulate a numeric value 
within a program. A family of routines has been added to 
the HP-UX system to access the current language and trans- 
form the string value to a numeric value and back. 

For each of the languages listed, there is a directory which 
contains all of the information unique to that language. For 
example, in the directory /usr/llb'nls trench are located tables 
for NLS library routines and message catalogs for com- 
mands that provide native language support. For the Ger- 
man user, there is another directory usr lib nls german which 
has the same structure as the French directory. Only the 
string german in the path name and the contents of the 
various files differentiate the German directory from the 
French directory. Thus the software in the base HP-UX 
product can uniformly access information for either French 
or German users. 

The string value is also used within a program to access 
the correct message catalog. For example, the pr command 
which formats lines of text for printing will look at the 
value of the LANG environment variable. Based on that 
value, it will open the message catalog in the proper direc- 
tory so messages will be in the user's native language. As 
described earlier, the message catalog for German will ap- 
pear as usr'lib'nls german pr.cat and that for French will have 
a path name of /usr/libnlsfrench/pr.cat. 

The HP-UX base product includes a number of com- 
mands ported from UNIX System V. 4.2BSD, and other 
sources, including HP. NLS has been incorporated into a 
number of these commands. For example, as mentioned 
earlier, the HP-UX version of the pr command is able to 
handle Italian and other languages while the original ver- 
sion was limited to only ASCII characters and American 
English messages. 

In many cases, a significant amount of development is 
required to extend the capabilities of a complex program. 
For example, (he Bourne shell (the standard UNIX com- 
mand interpreter) makes use of the eighth bit of each 
character that it processes. Therefore, the changes to allow 
8-bit characters to be used in Bourne shell directives re- 
quired a major overhaul of the program. 

A number of new commands have been added to those 
from AT&T or the University of California at Berkeley to 
maintain and use the NLS facilities of the HP-UX operating 



system. One set of tools allows you to extract messages 
from existing C programs (tindstr), replace selected messages 
with calls to the message catalog facility (insertmsg). and 
build from the extracted strings a message catalog (gencat). 
As the program continues to evolve, other messages may 
be added. However, the source for the message catalog can 
be extracted from the C program source code (findmsg) for 
retranslation of messages. 

HPWindows 9000 

HPWindows 9000 is the human interface for the HP-UX 
system running on the Series 300 family of computers. Its 
purpose is to provide the user with a convenient yet intui- 
tive interface to the multiprocessing capabilities of HP-UX 
systems by allowing the creation, manipulation, and con- 
trol of several graphics and terminal windows on a single 
bit-mapped display screen. Many of the concepts and mod- 
els are the same as those found in other window systems. 10 
However, there are some contributions special to HPWin- 
dows/9000. 

These contributions include an architecture that runs 
entirely as a set of user processes without requiring mod- 
ification of the kernel. The windows themselves allow com- 
plete occlusion where windows can overlap each other and 
programs can output to obscured windows. Likewise, op- 
erations such as movement and size alteration can be done 
to obscured windows. Applications can alternately choose 
to redraw previously obscured regions or have the window 
system do it automatically. The other major contribution 
is providing a wide range of accesses to the window system, 
including device emulators that allow existing applications 
to run without modification, commands for usual HP-UX 
control of the window system and libraries for output of 
characters, window control and manipulation, and con- 
trol of various forms of input from the keyboard or locator. 

The underlying architecture is a multiprocess model 
which is interconnected by two types of communication 
channels. The primary process, called the window man- 
ager, provides two services: support of the interactive user 
interface and management of resources. These resources 
include the keyboard and locator (mouse or tablet) devices, 
the screen area, and the necessary communication paths. 
The purpose of the secondary processes, called window 
types, is to emulate an alpha terminal or graphics display 
device. These window types serve as extensions to the 
window manager for doing such tasks as drawing the win- 
dow border and assisting with interactive features unique 
to the window type. This collection of processes is inter- 
connected by two types of communication channels: 
shared memory and pseudoterminal devices (pry). 

Several HP-UX kernel features are used by HPWindows/ 
9000. The primary communication channel is a pty in which 
all messages and asynchronous events are passed, either 
as read/write data, or as ioctl calls to the window manager. 
A normal terminal tty is a multipurpose device file with 
the kernel on one side controlling the physical device, and 
the user process on the other side communicating via the 
open, close, read, wnte. and ioctl system calls, pty device files 
are special in that they provide the features and interface 
of a tty device file, but user processes can communicate on 
both sides of the device file. The other communication 
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channel is shared memory where data is shared between 
the window manager and servers. Typically this data con- 
sists of window images and shared font images that must 
be consistent between all associated processes. Sema- 
phores are used to ensure the integrity of the shared mem- 
ory data by preventing other processes from reading a sec- 
tion of shared memory while another process is writing to 
it. Another necessary kernel feature is the select system call, 
which allows a process such as the window manager to 
multiplex I/O from several input devices and many pty files 
simultaneously, allowing it to respond to whichever chan- 
nel has data. Since windowing is a real-time application 
(i.e.. used for responsive tracking of the locator, routing of 
keyboard input, repainting windows after moves or sizes, 
etc.). real-lime process priorities are necessary. The order 
of priority from highest to lowest is window manager, win- 
dow types, and user applications. 

Since the purpose of windowing is to provide a visual 
interface, it is only natural that HPWindows/9000 be built 
in conjunction with the Starbase Graphics Library. The 
Starbase Library uses a layered architecture with a high- 
level user interface based on ANSI's Computer Graphics 
Interface standard and a low-level device handler interface. 
It is at the device handler interface that windowing is done. 
Windows required two important extensions to the device 
handlers. One is the concept of layers, which are required 
to manage the window images. Layers not only can be 
obscured (covered by other layers), but also can be written 
to independent of occlusion conditions. Portions of 
obscured layers that are not visible either support output 




Fig. 3. Typical display showing alpha and graphics windows 
on a Series 300 Computer running HPWindows/9000 



by writing to optional memory images or ignore output if 
repainting of these areas can be done by the window type 
or application. Whether or not repainting is handled by 
the user or system, there is no special knowledge required 
of obscured areas because they are handled by the device 
handler. The second extension to the device handlers is 
the addition of raster fonts. This capability allows different 
fonts such as Courier to be copied in various point sizes 
on the screen. Since windows are built using the Starbase 
Library, users can write programs that use either raw Star- 
base screen devices or the graphics window type by select- 
ing the appropriate driver. HPWindows/9000 works on 
monochrome or color, low- or high-resolution bit-mapped 
displays. 

The most natural way to use HPWindows/9000 is through 
its interactive user interface. The cognitive model it is based 
on is that of point-do (e.g.. select window 1 or move win- 
dow 3). These actions are done by picking sensitive sym- 
bols residing in the window border, each representing ac- 
tions that can be performed on the window. Such actions 
include move, size, pause, scroll, or change the window's 
appearance. The action of associating the keyboard to a 
window has no touch-sensitive symbol; this is done by 
selecting the interior area of the window. Changes to the 
echo representing the locator's position on the screen in- 
forms the user that a touch-sensitive area can be picked. 
A window can be represented in two forms — normal, which 
is the usual full window display, or iconic, which are small 
graphic representations of the window or the application 
running in the window. 

There are two types of menus— system and user defined. 
The system menu not only contains items for interactive 
operations such as move, but also provides the items to 
change the window's obscurity, create a new window, de- 
stroy a window, or exit the window system. The window 
system's interactive user interface can be customized to 
various application requirements (i.e., altering or limiting 
its capabilities). 

Window types are an integral part of HPWindows/9000 
because they emulate devices normally accessed by user 
applications. Window types allow applications that usu- 
ally deal directly with the device to run in the window 
system without modification. The first of two window 
types which are part of HPWindows/9000 is an alpha ter- 
minal, which emulates the features of an HP 2622 Terminal, 
except for its block and format modes, and adds the color 
capabilities found in an HP 2627 Terminal. The second 
window type is a graphics window, which provides access 
via the Starbase Library as if the window were a Starbase 
display device. 

Commands are provided for easy access to the window 
system from the shell programming environment. Such ac- 
cess includes the creation, deletion, listing, appearance, 
and manipulation of windows, changing of fonts, and con- 
trol of the window system. 

The library interface provides full programmability of 
the windowing system. Users not only have access similar 
to that of the above commands, but they also can control 
icons, signal detection, and handling of window events, 
menus, locator input, and echo control. 

Fast alpha and font manager library routines are provided 
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to allow the user to place raster text at arbitrary locations 
on the display screen or in a window. This capability allows 
the combining of text and graphics on a single device. Both 
libraries access the low-level drivers directly for maximum 
speed and cooperate fully with the window environment. 
The fast alpha text locations are specified by character 
column and line. An environment is created so that calls 
to the various routines cooperate with one another and 
COloi character enhancement information are handled 
automatically for the user. Intensive text manipulation ap- 
plications like terminal environments are easily created 
using the fast alpha scrolling, writing, and cursor manipu- 
lation routines. The font manager places text according to 
a given pixel location. Fonts can be mixed freely with dif- 
ferent styles and sizes. 
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CORRECTION 

'he louowtny ptirdgidtin missing >r> last months *65ue trom the ena ot James 
Chen's article on page 34 

Continuing Development 

The science of ultrasound power and intensity mea- 
surement is rapidly evolving and the associated regula- 
tory standards are continually being updated to reflect 
the latest state of the art. As a result, many changes and 
improvements have been incorporated into HP's ultra- 
sound power and intensity measurement program since 
this article was- first written and we are continuing to 
upgrade our measurement process to comply with cur- 
rent regulatory standards using the latest techniques and 
equipment. 
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A Protocol Analyzer for Local Area 
Networks 

This new analyzer allows 10 Mbit/s network monitoring, 
testing, and performance analysis independent of hardware 
and software composition. It permits a user to view network 
traffic, simulate node-to-node or network-wide traffic, and 
derive network statistics. 

by Gordon A. Jensen, Stephen P. Reames, Jerry D. Morris, Jeffrey H. Smith, Jeffrey Tomberlin, and 
James M. Umphrey 



MOST USERS of local area networks (LANs) expect 
their computers and peripherals to exchange data 
freely through standard Ethernet/IEEE 802.3 inter- 
faces. When the system is composed entirely of equipment 
from a single vendor such as HP, this is just what they 
should expect. They know that if the network doesn't per- 
form properly. HP will supply the support services needed 
to solve the problem. 

Unfortunately, few users are able to satisfy all of their 
networking needs with products supplied by a single ven- 
dor. Instead they must choose from a broad spectrum of 
products from a variety of vendors. Thus it is not at all 
unusual for users to connect equipment from two or more 
vendors to the same LAN only to discover that some incom- 
patibility prevents them from working together. Even 
though the equipment uses correctly designed and operat- 
ing LAN interfaces, the higher-level protocols often just 
won't communicate with each other. 

Who can users call when two pieces of equipment from 
different vendors don't communicate? In most cases neither 
vendor will take on the problem; it will be up to the users 
to solve it themselves. 

Another problem with multivendor networks is network 
management. Most LAN vendors can supply software that 
is reasonably adequate for managing the portion of the 
network supplied by them. Typically each node contains 
software that allows it to compute statistics on its own 
activities and report these back to a master station. Because 
each vendor uses a different system for reporting, however, 
no single vendor can gather and present statistics for the 
entire network. 

The HP 4971S LAN Protocol Analyzer (Fig. 1) was de- 
veloped to solve these problems. It is dedicated to monitor- 
ing and simulating a network and gathering data for net- 
work management independently of the hardware and soft- 
ware that make up the network. 

Overview of the HP 4971 S 

For a protocol analyzer to be capable of trapping and 
analyzing all of the network traffic for a 10-megabit/s LAN, 
dedicated high-speed hardware is essential. In the HP 
497 IS. this hardware includes a LAN interface processor, 
two hardware trap machines or filters, a high-speed 1M- 
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byte two-port RAM buffer, and a separate LAN transmitter 
(see Fig. 2). 

The LAN interface hardware is based on the Intel 82586 
LAN coprocessor. This chip enables the analyzer to capture 
all traffic on the network independent of address or FCS 
(frame check sequence) status, Additional hardware was 
designed around Ihis interface to ensure that the analyzer 
can capture and process all network traffic in real time 
under any loading conditions. 

Many LAN interfaces can miss packets when large num- 
bers of small frames (<30 bytes) are received at minimum 
interframe spacing. These small frames are usually colli- 
sion fragments (runts) found on extremely heavily loaded 
networks approaching maximum network span. To avoid 




Fig. 1. The HP 4971S LAN Protocol Analyzer is designed lor 
local area network troubleshooting and management It can 
monitor and simulate network traltic and gather data indepen- 
dently of network hardware and software. 
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this potential problem, the HP 4971 S incorporates a custom 
runt packet filter that removes packets less than 512 bits 
long. This circuit filters the serial data stream between the 
LAN attachment unit interface (AUI) and the 82586. 

Capturing bad frames on the network permits identifica- 
tion and analysis of errors occurring at levels 1 and 2 of 
the ISO OSI model, such as marginal connections and MAU 
(media access unit) failures. Collision counting hardware 
also permits the user to monitor one of the important indi- 
cators of network loading. Although normally only signif- 
icant at network loads exceeding 40%, the collision rate 
can indicate faulty hardware on the network or let the 
system manager know when it may be time to reconfigure 
the network. 

Because of the high data rate and the potentially large 
numbers of independent logical channels all operating at 
once, a filtering mechanism that passes only frames of in- 
terest to the user is essential. For example, if an IEEE 802.3 
network is loaded at 10% of capacity, one megabyte of data 
appears on the network every eight seconds. Since a con- 
versation between two nodes of interest may take several 
minutes, collecting all of the data on the network to study 
that one conversation would be impractical. The filtering 
function allows the HP 4971S to retain in its capture buffer 
only those frames that meet a predefined specification. 

When a frame is received by the HP 4971S, it is loaded 
into the capture buffer in a linked list data structure. This 
loading process also passes the data through some special- 
purpose pattern recognition hardware called the trap 
machine. The trap machine outputs the results of a com- 
parison with sixteen different patterns up to 61 bytes long 
to the system microprocessor. If at least one of the sixteen 
patterns is matched by the received frame, the system mi- 
croprocessor knows that this is a frame that the user wishes 
to keep and no action is taken. If, on the other hand, the 
received frame does not match any of the predefined pat- 
terns, the processor deletes the frame. It does this by ma- 
nipulating pointers in the linked list to remove the buffers 
taken by the frame. It places these buffers at the end of the 
free list where they can be reused. When the HP 4971 S 
operates in a circular buffer mode to observe data continu- 
ously, the processor keeps a constant number of buffers 
between the head and the tail of the list by reallocating the 
buffers in place. 

The capture buffer is a lM-byte dual-port RAM. The 
receive hardware writes the captured data into one port 
and the system microprocessor does its pointer manipula- 
tions through the other port. This structure is required 



because of the high data rate: a single bus cannot provide 
the needed bandwidth. All received frames are loaded into 
the capture buffer. This means that if a user does wish to 
look at every single frame around a trigger point, for exam- 
ple, then the filter mechanism is simply not used. 

Another useful feature of the HP 4971S is the ability to 
view frames as it transmits them onto the network. Because 
an IEEE 802.3 network is not deterministic, it is impossible 
to know exactly when a given frame will be sent after a 
program executes a send message statement. The ability to 
see the analyzer's transmit frames removes all ambiguity 
from this situation, allowing the relative timing of transmit 
and receive frames to be observed during a simulation. 
This feature requires a separate transmitter and receiver in 
the instrument, although only one transceiver is needed 
for attachment to the network. 

Software Features Enhance Ease of Use 

To minimize the complexity of LAN protocol analysis, 
the HP 4971 S software has been designed with ease of use 
as a primary goal. Using softkeys to select major functions 
eases the task of instrument control, while screen editing 
capability aids data entry and presentation. 

To get a novice user started quickly, a two-button net- 
work monitoring function is provided. As shown in Fig. 
3, the user needs only to select the Monitor Network and Start 
Monitor softkeys to begin capturing and viewing data on the 
LAN. Snapshots of the data are displayed as it is being 
stored in the capture buffer. Once the buffer is full, control 
transfers automatically to the Examine Data menu, where the 
user can easily scroll through all of the frames stored. 

When dealing with a packet-switched network capable 
of supporting hundreds of nodes, the difficulty of identify- 
ing a single node or connection quickly becomes apparent. 
Although each node has a unique six-byte address which 
is clearly displayed in the source and destination fields of 
a frame, not many users can remember more than a few of 
these addresses or the devices they represent. To help the 
user with this problem, the HP 4971S provides a node 
name table. With it, each node address can be assigned an 
alphanumeric name to describe the device and/or location 
on the net. Once assignments have been made, the user 
has the option of viewing and entering addresses by name 
throughout the HP 4971 S menus. 

As previously indicated, it is often desirable to view only 
a subset of the total network traffic. The dedicated hardware 
trap machines make this possible, but it is up to the user 
to specify which subset of the traffic is of interest. This 
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process of data filter specification is made easy by the Edit 
Filters menu. 

A data filter is analogous to a frequency-domain 
bandpass filter. Only input that is compatible with the 
parameters of the filter is able to pass through. The HP 
4971S data filters are used to eliminate traffic that is not 
of interest and to select among the frames that remain. 

Up to 16 data filters can be defined and used simultane- 
ously. The filters are created by using a softkey-driven filler 
definition menu. This menu is also used to name the newly 
created filters and to enter values into their most commonly 
used fields (see Fig. 4). The 6-byte Ethernet/IEEE 802.3 
node addresses can be entered in hexadecimal format, or 
by using softkeys that display names from the node name 
table, or by entering node names directly from the 
keyboard. To permit all defined data filters to be displayed 
together, this menu does not display the filter data fields. 

To use the data filters for capturing frames based on the 
values of higher-level protocol fields, it is necessary to 
specify subfields within the Ethernet/IEEE 802.3 data field. 
An additional menu was designed to allow the user flexi- 
bility in specifying these fields (see Fig. 5). The HP 4971S 
provides 47 byte positions to be defined in the frame data 
field. These bytes can be located anywhere in the data field 
and can be formatted into as many as thirteen separate 
subfields in each data filter. For convenience, subfields 
can be named. Within each subfield. bytes can be entered 



and viewed using ASCII, EBCDIC, hexadecimal, or binary 
data codes. In binary, both the least-significant-bit-on-the- 
right and the least-significant-bit-on-the-left modes are 
available. In the hexadecimal mode, individual half bytes 
can be set to "don't care'" and in the binary modes indi- 
vidual bits can be set to "don't care." In all data codes, 
bytes can be set individually to "anything except" the quan- 
tity entered (i.e., the logical NOT of the quantity entered). 
Thus, for example, a filter can be set to accept any character 
that is not an AK control character in a given byte position. 

A third filter definition menu called the frame traits 
menu allows the HP 4971S to filter on the presence or 
absence of some frame reception errors. Frames can be 
accepted or rejected if they have a good or bad frame check 
sequence (FCS). if they are misaligned (the FCS is bad and 
the number of bits in the frame is not evenly divisible by 
eight), or if they are runt frames (they contain fewer than 
64 bytes). In addition, jabbering frames (frames containing 
more than 1518 bytes) can be recognized by using the 
Minimum Length and Maximum Length fields in the filter defini- 
tion menus. 

The operator can use a similar set of menus to define up 
to sixteen messages, which can be used by a softkey-driven 
programming language to put user-defined traffic onto the 
network. An overview menu handles the Ethernet/IEEE 
802.3 header fields and permits selection of the message 
length and FCS. The length of each message can range from 
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one byte to 2022 bytes. If the message length is less than 
64 bytes or more than 1518 bytes, it is not a legal Ethernet 
IEEE 802.3 frame, so a warning message is displayed. A 
message can be sent with a good, bad. or selected FCS. 

A detail menu expands the data field, if any, of any 
message that has been defined. The data field contents can 
be entered from the keyboard using ASCII, EBCDIC, or 
hexadecimal data codes. A useful feature allows any de- 
fined message or any frame in the receive buffer to be 
copied and edited. Individual bytes can also be inserted 
or deleted. 

A third message menu permits any message to be dis- 
played and edited using the subfield labels, positions, and 
lengths defined for any filter. This greatly facilitates the 
entry of values into the fields of higher-level protocols. 

Because of the amount and complexity of the traffic that 
the HP 4971S can collect from a network during a run. 
particular attention was devoted to ensuring that frames 
can be displayed in formats that are meaningful to the user. 
The entire frame, from the first byte of the header through 
the last byte of the data field, can be viewed, regardless of 
its length. Address fields from the Ethernel/IEEE 802.3 
header can be displayed in hexadecimal code or by using 
the equivalent node names as defined in the node name 
table. The Ethernet/IEEE 802.3 data field can be displayed 
using ASCII-7. ASCII-8. EBCDIC, or hexadecimal character 
codes. A 32-bit time stamp with a resolution of 32 micro- 
seconds is stored with each frame when it is received. 
Several time stamp display formats are possible, including 
time of day and time from the end of the previous frame. 
Additional fields identify the filters that accepted each 
frame and any error conditions that may have been detected 
during reception. 

If ihe lengths of the frames permit, multiple frames are 
displayed simultaneously on the screen, so that a frame 
can be viewed in the context in which it was received. 
Optional suppression of the data field, the Ethernet/IEEE 
802.3 header, and/or the physical frame data can be used 
to permit more frames to be displayed simultaneously. Ad- 
ditionally, a one-line summary format is available thai 
shows only the node addresses, frame length, fillers 
matched, and reception errors. 

Support for higher-level protocols is also available in Ihe 
display of received frames. A Filler Formal display mode 
displays received frames using the subfield format and 
labels that match the filter that accepted it. Key protocol 



fields can be easily identified in this way. 

For complex troubleshooting and traffic simulation, a 
softkey-driven programming language is included. Based 
upon the algorithmic language designed for the HP 495X 
Protocol Analyzers.' it provides even inexperienced pro- 
grammers with the means to automate testing and simplify 
data analysis. 

At the head of the program is the buffer control command 
line. With it. the user selects which frames (if any) to collect 
in the receive buffer when the program is executed. The 
data filters can be accessed here for both filtering and trig- 
gering. The filtering process is enabled by choosing to Store 
frames matching any subset of the 16 defined data filters. 
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Triggering options are starting with, centered about, or end- 
ing with any subset of the 16 defined data filters, although 
the user may also choose simply to store until full or 
nonstop. 

The remainder of the program is used to manipulate the 
received data. By softkey choices, a great variety of pro- 
grams can be easily constructed. For example, a program 
to display only those frames matching a single filter can 
be written with the few keystrokes shown in Fig. 6. This 
program can be used to display only frames sent by a node 
while storing frames sent and received by it. or to locate 
those frames in the receive buffer during postprocessing. 
More complex programs can measure time intervals using 
up to sixteen timers, count frames or collisions using up 
to sixteen counters, and transmit frames using the sixteen 
messages defined in the Message menu. Programs can be 
written to run in real time so long as the average traffic 
level through the filters is below the typical maximum 
network loading of 40%. For traffic levels above this, data 
will still be captured in real time but must be analyzed by 
postprocessing. 

For preserving (he node name table, data filters, mes- 
sages, programs, and captured data, a Disc Functions menu 
is provided. Configuration parameters can be saved as net- 
work files, and data from the receive buffer can be selec- 
tively stored in data files. This information can be loaded 
back at any time for additional network testing or data 
postprocessing. Both hard and flexible discs are supported, 
with a maximum on-line storage capacity of 40 megabytes. 

Problem Solving 

Users are faced with protocol incompatibilities almost 
every time they connect equipment from different vendors 
to the same network. This may happen because the vendors 
have interpreted the same protocol specification differently 
or because one vendor has defined an entirely new protocol 
that simply will not communicate with thai of another 
vendor. It could even be that one device has a software 
bug that only appears when interacting with another device 
through the LAN. Finding these problems can be a real 
challenge, but the HP 4971S makes the job easier. 

Suppose, for instance, that a LAN manager connects a 



new personal computer to a network and suddenly starts 
getting protocol errors reported by one of the host comput- 
ers on the network. The PC seems to work fine with other 
devices on the network, and other PCs from the same man- 
ufacturer work with the host, so what is the problem? Using 
the HP 4971S, a frame from one of the "working" PCs to 
the host can be captured and compared to a like frame from 
the "bad" PC. The Filter Format option breaks out the TCP 
IP protocol fields and makes the problem clear (see Fig. 7). 
The bad PC is somehow setting its TCP window size to 
FE-00, a negative number! Further investigation might re- 
veal that the new PC came with a new revision of software, 
which contains a previously undiscovered bug. 

More obscure errors can be located using the special 
protocol analysis programs. It could be that a bad frame 
appears on the network at seemingly random times for 
unknown reasons. Even when the source of the bad frame 
has been identified, the cause for its unexpected transmis- 
sion may not be understood. To discover why the error 
occurs, the user can write a program to store all frames to 
and from the problem node centered about the appearance 
of the bad frame. Since the error occurs infrequently, the 
user can also tell the program to beep when the error is 
detected. The next time the bad frame appears, the HP 
4971 S will present a trace of the frames before and after 
it. With this information, cause and effect can be clearly 
seen. 

In addition to protocol analysis, the HP 4971 S can be 
used to investigate network performance problems. If there 
is reason to think that a network may be overloaded during 
certain peak times, a program might be written to measure 
traffic over one-hour periods for the fourteen prime shift 
hours of the day (see Fig. 8). The network manager starts 
the program when beginning work at 6:00 a.m. The next 
morning, the traffic history of the previous day is waiting. 
From this data the manager can determine the peak use 
times of the network and begin an investigation of the 
traffic during those times. Once the bottleneck is discov- 
ered, appropriate action can be taken. 

Now suppose that the traffic measurement indicates that 
there is no general overloading of the network at any time, 
but the users are still complaining about the response time 
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of a particular host. The network manager can write a sim- 
ple simulation program to send an XID message to the host 
and measure the time it takes to get a reply (see Fig. 9). If 
the measurement indicates that there is indeed a slow re- 
sponse, then further investigation may be required. It could 
be that the host software puts LAN communications at too 
low a priority and that some optimization can be done. In 
a multinetvvork environment, it may be necessary to read- 
just the internet routing tables. 

Another tool for network problem-solving with the HP 
4971S is the remote testing option. This gives the user the 
ability to test a remote network using the same features 
that are available for testing the local network. For example, 
a user can remotely run a program that looks for frames 
with bad FCS fields. This program would actually be run- 
ning on a slave HP 4971S attached to the remote network, 
but the softkeys and results would appear on the master 
HP 4971 S display just as if the program were running on 
the master unit. 

In remote mode, the master and slave HP 4971 Ss com- 
municate over an RS-232-C/V.24 link. This link will usually 
be over a dial-up phone line, but it could be a leased line 
or even a direct connection if the slave HP 4971S is located 
close to the master. To ensure error-free communication 
between the master and the slave, one of two protocols is 
used: DDCMP or encoded DDCMP.* 

More than one slave HP 4971S can be controlled by a 
master. For example, someone at site 1 could use an HP 

'DDCMP is a protocol standard dovetoped by Digital Equipment Corporation 

Store: all frames 
nonstop 



4971S as a master to make the slave units at sites 2 and 3 
start executing standard test programs that collect some 
statistical information of interest for their networks. 

While the slave units are collecting data, the unit at site 
1 can be used locally for some management or diagnostic 
purpose or as a master to control a slave on some other 
network. When this task is complete the unit at site 1 can 
once again become a master to examine the statistics that 
have been collected by the slave units at sites 2 and 3. 

Conclusion 

In summary, the ability of the HP 497 IS to acquire any 
network frame independent of the network vendor(s) and 
network traffic conditions provides the capability for net- 
work troubleshooting and management. The softkey-con- 
trolled system is extremely user friendly, providing flexi- 
bility through an easy-to-use programming language. These 
features allow straightforward debugging of network 
hardware and Ethernet/IEEE 802.3 protocols. With rela- 
tively simple programs, the user can debug higher-level 
protocols and gather statistics for use in managing a local 
area network. 
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Block 1: 

start timer Tot Tim* 

and then 

start frame counter Tot Frame 

and then 
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Block II 
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Block 5: 

When timer 2nd hour exceeds 3600 seconds then go to block 7 
else when frame matches any Frame then go to block 6 
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Fig. 8. To check lor network over- 
loading during peak hours, a pro- 
gram can be written to measure 
trallic over one-hour periods lor 
the lourteen prime shift hours ol 
the day. 



JULY 1986 HEWLETT-PACKARD JOURNAL 47 



© Copr. 1949-1998 Hewlett-Packard Co. 



Store: frame* matching XID Command 
or XID Response 
nonstop 

Block 1: 

Send message XID Command Indiv 
and then 

when frame matches XID Command then go to block 2 

Block 2: 

Start timer Duration 
and then 

When frame matches XID Response then go to block 3 

Block 3: 

Stop timer Duration 

and then 
Start display 

and then 
Stop test 
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Fig. 9. To test the response time 
ol a particular computer, a pro- 
gram can be written to send an 
xid toopback message to the com- 
puter and measure the time it 
takes to get a reply 
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